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>
Hi,
'sed' hasn't been updated in IPFire for a few years - I thought it could
be worthy an update:
Excerpt from 'NEWS':
"* Noteworthy changes in release 4.4 (2017-02-03) [stable]
sed could segfault when invoked with specific combination of newlines
in the input and regex pattern. [Bug introduced in sed-4.3]"
"Noteworthy changes" from release 4.2.2 to 4.3 can be found in 'NEWS' file, too much
to list them all...
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Add new generated CA bundle files to updater and remove
accidentally inserted blank line at the end of certdata.txt .
Signed-off-by: Peter Müller <peter.mueller@link38.eu>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The removed patches are included in this version so there is no need
that we apply them.
Signed-off-by: Jonatan Schlag <jonatan.schlag@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Added 'Captive' localization string in 'de/en.pl'.
After a fresh install of Core 117, the system log shows a blank line
for 'Captive Portal' entries.
Deleted translation for 'Captive menu' and changed '30-network.menu' accordingly
to avoid duplicate translation strings.
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Changes from 9.52 to 9.53:
- 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>
Excerpt from 'NEWS':
"* 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>
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>
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>
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>
