This reverts commit d404b1dba2.
Intel has pulled these microcode updates because of
random system reboots and systems becoming unstable.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
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>
