Matthias Fischer [Fri, 26 Jan 2018 16:43:24 +0000 (17:43 +0100)]
clamav: Update to 0.99.3
Excerpt from 'README':
"ClamAV 0.99.3 is a hotfix release to patch a set of vulnerabilities.
- fixes for the following CVE's: CVE-2017-6418, CVE-2017-6420,
CVE-2017-12374, CVE-2017-12375, CVE-2017-12376, CVE-2017-12377,
CVE-2017-12378, CVE-2017-12379, CVE-2017-12380.
- also included are 2 minor fixes to properly detect openssl install
locations on FreeBSD 11, and prevent false warnings about zlib 1.2.1#
version numbers."
For details see:
http://blog.clamav.net/2018/01/clamav-0993-has-been-released.html
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org> Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Jonatan Schlag [Fri, 19 Jan 2018 18:29:02 +0000 (19:29 +0100)]
python3-libvirt: drop this package
Since it is some work to update this package accordingly to the libvirt
version and facing the fact that I know nobody who using this I suggest to drop this. If we
need this later we can just revert the commit.
Signed-off-by: Jonatan Schlag <jonatan.schlag@ipfire.org> Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Matthias Fischer [Wed, 24 Jan 2018 07:32:24 +0000 (08:32 +0100)]
wget: Update to 1.9.4
Excerpts from changelog (Details => http://git.savannah.gnu.org/cgit/wget.git):
"Switch off compression by default
Gzip compression has a number of bugs which need to be ironed out before we can support it
by default. Some of these stem from a misunderstanding of the HTTP spec, but a lot of them
are also due to many web servers not
being compliant with RFC 7231.
With this commit, I am marking GZip compression support as experimental
in GNU Wget pending further investigation and the addition of tests.
* src/http.c (gethttp): Fix bug that prevented all files from being decompressed
* src/host.c (sufmatch): Fix to domain matching
Replace HTTP urls with HTTPS where valid
Avoid redirecting output to file when tcgetpgrp fails
* src/log.c (check_redirect_output): tcgetpgrp can return -1 (ENOTTY),
be sure to check whether a valid controlling terminal exists before
redirecting. (Fixes: #51181)
Fix heap overflow in HTTP protocol handling (CVE-2017-13090)
Fix stack overflow in HTTP protocol handling (CVE-2017-13089)"
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org> Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- 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>
projects / ipfire-2.x.git / log
