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>
Since fireinfo.ipfire.org is now supporting HTTPS, the
links in the WebUI should point to the secure version of the site.
Signed-off-by: Peter Müller <peter.mueller@link38.eu>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This is no longer needed and in the telephone conference
on Dec 4th, it was decided to drop it.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This didn't build and run in ages and has been removed from
the repositories quite a while ago.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
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>
This is EOL upstream for over ten years now and therefore
we cannot continue to support this either.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Make Apache transmit a CSP (Content Security Policy) header
for WebUI and Captive Portal contents.
This prevents some XSS and content injection attacks, especially
in case no transport encryption (Captive Portal!) can be used.
Signed-off-by: Peter Müller <peter.mueller@link38.eu>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
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>
These are not considered secure anymore but are unfortunately
still needed in some cases (legacy hardware, ...).
Signed-off-by: Peter Müller <peter.mueller@link38.eu>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
