- Read Drive Capacity fixes from Iestyn Walters.
- SET MAX ADDRESS fixes from Tom Yan <tom.ty89@gmail.com>.
- added --security-prompt-for-password to --security-help output.
- fwdownload changes from Jihoon Lee.
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org> Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
"* Noteworthy changes in release 1.9 (2018-01-07) [stable]
** Bug fixes
gzip -d -S SUFFIX file.SUFFIX would fail for any upper-case byte in SUFFIX.
E.g., before, this command would fail:
$ :|gzip > kT && gzip -d -S T kT
gzip: kT: unknown suffix -- ignored
[bug present since the beginning]
When decompressing data in 'pack' format, gzip no longer mishandles
leading zeros in the end-of-block code. [bug introduced in gzip-1.6]
When converting from system-dependent time_t format to the 32-bit
unsigned MTIME format used in gzip files, if a timestamp does not
fit gzip now substitutes zero instead of the timestamp's low-order
32 bits, as per Internet RFC 1952. When converting from MTIME to
time_t format, if a timestamp does not fit gzip now warns and
substitutes the nearest in-range value instead of crashing or
silently substituting an implementation-defined value (typically,
the timestamp's low-order bits). This affects timestamps before
1970 and after 2106, and timestamps after 2038 on platforms with
32-bit signed time_t. [bug present since the beginning]
Commands implemented via shell scripts are now more consistent about
failure status. For example, 'gunzip --help >/dev/full' now
consistently exits with status 1 (error), instead of with status 2
(warning) on some platforms. [bug present since the beginning]
Support for VMS and Amiga has been removed. It was not working anyway,
and it reportedly caused file name glitches on MS-Windowsish platforms."
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org> Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
With Microsoft's new style of downloading updates,
where portions of a patch are requested multiple times per second,
it has become extremely common for downloads to reach > 100%.
Due to an early unlinking of the "lock" file, there is a big window of
opportunity (between the unlink and wget actually saving some data)
for multiple download/wget threads to start, adding to the same file.
So not only is bandwidth wasted by duplicate downloads running
simultaneously, but the resulting file is corrupt anyway.
The problem is noticed more often by low bandwidth users
(who need the benefits of updxlrator the most)
because then wget's latency is even longer, creating
a very wide window of opportunity.
Ultimately, this needs something like "flock", where the
file is set and tested in one operation. But for now,
settle with the current test / create lock solution, and
just stop unnecessarily releasing the lock.
Since the file already exists as a lock when wget starts,
wget now must ALWAYS run with --continue, which
works fine on a zero-sized file.
Signed-off-by: Justin Luth <jluth@mail.com> Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Justin Luth [Sat, 30 Dec 2017 05:48:37 +0000 (08:48 +0300)]
updxlrator: show hostaddr in debuglog
There is nowhere in the debuglog any indication of
which client is requesting the file that updxlrator
is providing (or caching). Especially for those
huge Windows 10 downloads, it is valuable to
see which client is requesting them, especially
when the same client requests the same download
multiple times a second.
This only impacts users who turn on debugging.
Signed-off-by: Justin Luth <jluth@mail.com> Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Justin Luth [Sat, 30 Dec 2017 19:12:01 +0000 (22:12 +0300)]
Fix bug 11558 updxlrator: use mirror mode for SHA1, filenames
Most Microsoft updates now contain an SHA1 hash in the filename.
Since these files are uniquely identifiable, use mirror mode
(which creates a hash of just the filename instead of the entire URL)
to cache them. (But first check the URL cache to see if it
has been downloaded as a URL already.)
This is a HUGELY needed fix. Windows 10 updates are 5+ GB
per month, and we lose several days of bandwidth downloading
duplicates from different mirrors. Sometimes a single client
will request the same patch from multiple mirrors. That's bad.
This patch will save a ton of bandwidth, and lots of disk space.
The patch limits the SHA1 test to microsoft only, but it
could be easily expanded to other vendors if there is a need.
Signed-off-by: Justin Luth <jluth@mail.com> Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Justin Luth [Fri, 29 Dec 2017 14:12:27 +0000 (17:12 +0300)]
Fix bug 10504: match download's sourceurl mangling in, updxlrator
Updatexlrator stores its files in a hash of the URL.
The download utility mangles the URL for [+/~], but
the updxlrator only does it for [/]. Thus, download
stores the result as one hash, and updxlrator looks for it
with a different hash. The result is that the file is
re-downloaded every time by both the client, and updxlrator.
This is fixed by making updxlrator mangle the url in the
same way as the downloader. apt-get install g++ would
be a good test for this.
Signed-off-by: Justin Luth <jluth@mail.com> Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Michael Tremer [Sat, 16 Dec 2017 12:35:12 +0000 (12:35 +0000)]
Drop cacti
This package was discontinued upstream and seems to be
a bit more lively again. However, nobody of the team
wants to maintain cacti. Therefore this is being dropped
for now.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Peter Müller [Sun, 3 Dec 2017 17:10:47 +0000 (18:10 +0100)]
prevent IE from interpreting HTML MIME type
Add X-Content-Type-Options header to prevent Internet Explorer
from interpreting the MIME type of a server answer on its own,
which could lead to security risks.
Signed-off-by: Peter Müller <peter.mueller@link38.eu> Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Michael Tremer [Fri, 8 Dec 2017 13:58:26 +0000 (13:58 +0000)]
openssl: Update to 1.0.2n
OpenSSL Security Advisory [07 Dec 2017]
========================================
Read/write after SSL object in error state (CVE-2017-3737)
==========================================================
Severity: Moderate
OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state"
mechanism. The intent was that if a fatal error occurred during a handshake then
OpenSSL would move into the error state and would immediately fail if you
attempted to continue the handshake. This works as designed for the explicit
handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()),
however due to a bug it does not work correctly if SSL_read() or SSL_write() is
called directly. In that scenario, if the handshake fails then a fatal error
will be returned in the initial function call. If SSL_read()/SSL_write() is
subsequently called by the application for the same SSL object then it will
succeed and the data is passed without being decrypted/encrypted directly from
the SSL/TLS record layer.
In order to exploit this issue an application bug would have to be present that
resulted in a call to SSL_read()/SSL_write() being issued after having already
received a fatal error.
This issue does not affect OpenSSL 1.1.0.
OpenSSL 1.0.2 users should upgrade to 1.0.2n
This issue was reported to OpenSSL on 10th November 2017 by David Benjamin
(Google). The fix was proposed by David Benjamin and implemented by Matt Caswell
of the OpenSSL development team.
rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738)
=========================================================
Severity: Low
There is an overflow bug in the AVX2 Montgomery multiplication procedure
used in exponentiation with 1024-bit moduli. No EC algorithms are affected.
Analysis suggests that attacks against RSA and DSA as a result of this defect
would be very difficult to perform and are not believed likely. Attacks
against DH1024 are considered just feasible, because most of the work
necessary to deduce information about a private key may be performed offline.
The amount of resources required for such an attack would be significant.
However, for an attack on TLS to be meaningful, the server would have to share
the DH1024 private key among multiple clients, which is no longer an option
since CVE-2016-0701.
This only affects processors that support the AVX2 but not ADX extensions
like Intel Haswell (4th generation).
Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732
and CVE-2015-3193.
Due to the low severity of this issue we are not issuing a new release of
OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it
becomes available. The fix is also available in commit e502cc86d in the OpenSSL
git repository.
OpenSSL 1.0.2 users should upgrade to 1.0.2n
This issue was reported to OpenSSL on 22nd November 2017 by David Benjamin
(Google). The issue was originally found via the OSS-Fuzz project. The fix was
developed by Andy Polyakov of the OpenSSL development team.
Note
====
Support for version 1.0.1 ended on 31st December 2016. Support for versions
0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer
receiving security updates.
References
==========
URL for this Security Advisory:
https://www.openssl.org/news/secadv/20171207.txt
Note: the online version of the advisory may be updated with additional details
over time.
For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
projects / ipfire-2.x.git / log
