Upstream does not provide a sha512 hash anymore.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Release notes:
https://dovecot.org/pipermail/dovecot/2019-August/116876.html
Fixes
* CVE-2019-11500: ManageSieve protocol parser does not properly handle
NUL byte when scanning data in quoted strings, leading to out of
bounds heap memory writes. Found by Nick Roessler and Rafi Rubin.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Release notes:
https://dovecot.org/pipermail/dovecot/2019-August/116874.html
Fixes
* CVE-2019-11500: IMAP protocol parser does not properly handle NUL byte
when scanning data in quoted strings, leading to out of bounds heap
memory writes. Found by Nick Roessler and Rafi Rubin.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
An issue was discovered in urllib2 in Python 2.x through 2.7.16 and urllib
in Python 3.x through 3.7.3. CRLF injection is possible if the attacker
controls a url parameter, as demonstrated by the first argument to
urllib.request.urlopen with \r\n (specifically in the query string after a ?
character) followed by an HTTP header or a Redis command.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
CVE-2018-16872: A flaw was found in qemu Media Transfer Protocol (MTP). The
code opening files in usb_mtp_get_object and usb_mtp_get_partial_object and
directories in usb_mtp_object_readdir doesn't consider that the underlying
filesystem may have changed since the time lstat(2) was called in
usb_mtp_object_alloc, a classical TOCTTOU problem. An attacker with write
access to the host filesystem shared with a guest can use this property to
navigate the host filesystem in the context of the QEMU process and read any
file the QEMU process has access to. Access to the filesystem may be local
or via a network share protocol such as CIFS.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
- Remove first patch (already in version)
- Remove second patch (not needed since merge of
https://github.com/wolfcw/libfaketime/pull/161)
- Add hash for license file
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Security fixes:
CVE-2019-13057: Fixed slapd to restrict rootDN proxyauthz to its own databases
CVE-2019-13565: Fixed slapd to initialize SASL SSF per connection
Full changelog:
https://www.openldap.org/lists/openldap-announce/201907/msg00001.html
Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
[Peter: fix sha256 hash line]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add upstream patch with a workaround to incompatible change in kernel
headers.
Regenerate the v4l2_pix_fmts.h header which is pre-generated from
v4l2_pix_fmts.in in the strace tarball.
Fixes:
http://autobuild.buildroot.net/results/5494c9e21e623a9b7d87e06d86ed5e95d696c21a/
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
>From the release notes:
- Fix an out-of-bounds read of maximal two bytes for truncated RVA2 frames
(oss-fuzz-bug 15975). The earlier fix around the same location needed
one thought more. Actually, another though was needed, oss-fuzz-bug 16009
documents the incomplete fix.
- Fix an invalid write of one zero byte for empty ID3v2 frames that demand
de-unsyncing (oss-fuzz-bug 16050).
- Fix dynamic build with gcc -fsanitize=address (check for all dl functions
before deciding that separate -ldl is not needed).
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that we can order packages from biggest to smallest, it makes sense
to assign the most aggressive colours to the biggest packages.
As such, reorder the current colours so that we have, in order:
- red-ish
- orange-ish
- yellow-ish
- purple-ish
- eggplant-ish (is that even a colour? :-] )
- some-indeterminate-blue-ish
- dark-green-ish
- light-green-ish
For the previous, smallest-first ordering, it does not matter much what
the ordering is: the actual colours are still somewhat-unpredictably
assigned to packages, depending on the cut-off limit...
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Currently, the packages are sorted smallest first, and biggest last
(with unknown and others second-to-last and last, resp.).
Add an option to invert the ordering (but keeping unknown and others at
their current positions).
This has the nice side effect that we can now control the colours
assigned to the biggest package(s), as the colours are cycled from the
first to the last. Currently, the biggest packages gets a redish colour,
which is appropriate, but the second gets a greenish one, which is not
as appropriate (but changing that can come later).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
When dealing with embedded devices, storage is more often than not some
kind of flash device, on which the memory is usually counted as powers
of 1024 instead of powers of 1000. As such, people may prefer reports
using IEC prefixes [0] instead of the SI prefixes.
Add an option to that effect.
We use argparse's ability to use custom actions [1] [2], to provide a
set of options that act on a boolean, but has a single help entry and
internally ensures consistency of the settings. We could have been using
the more conventional store_true/store_false actions instead, but that
would have meant either two help entries, one for each set of options,
and/or some logic after parse_args() to check the validity of the
settings.
[0] https://en.wikipedia.org/wiki/Binary_prefix
[1] https://docs.python.org/2/library/argparse.html#action
[2] https://docs.python.org/2/library/argparse.html#argparse.Action
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Currently, we group packages that contribute less then 1%, into the
"Other" category.
However, in some cases, there can be a lot of very comparatively small
packages, and they may not exceed this limit, and so only the "Others"
category would be displayed, which is not nice.
Conversely, if there are a lot of packages, most of which only so
slightly exceeding this limit, then we get all of them in the graph,
which is not nice either.
Add a way for the developers to pass a different cut-off limit. As for
the dependency graph which has BR2_GRAPH_DEPS_OPTS, add the environment
variable BR2_GRAPH_SIZE_OPTS to carry those extra option (in preparation
for more to come, later).
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
[Arnout:
- remove empty base class definition from Config;
- use parser.error instead of ValueError for invalid argument.]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Currently, we forcibly report sizes in multiple of Kilobytes. In some
big configurations, the sizes of the system as a whole, as well as that
of individual packages, may exceed megabytes, and when some artistic
assets get used, even the gigabyte may get exceed.
These big sizes are not easy to read when expressed in kilobytes.
Additionally, some very small packages might have sizes below the
kilobyte (and when we can specify the cut-off grouping size, they may
get reported), and thus the size displayed for those would be 0 kB.
Add a helper function that can format a floating-point size into a
string with all the appropriate formatting:
- there are at least 3 meaningfull digits visible, i.e. we display
"3.14" or "10.4" instead of just "3" or "10", but for big number we
don't care about too many precision either, so we report "100" or
"1000", not "100.42" or "1000.27";
- the proper SI prefix is appended, if needed.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Currently, the "unknown" category may be reported anywhere, so it does
not really stand out when there are a lot of packages in the graph.
Move it towards the end, but right before the "other" category, so that
it is a bit more visible. Like for Others, don't report it if its size
is zero.
Also, make it title case (i.e. "Unknown" instead of "unknown").
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
It is nicer overall to have a main() function, like all our other
scripts tend to have too.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
There are three E501 warnings returned by flake8, when run locally,
because we enforce a local 80-char limit, but that are not reported by
the gitlab-ci jobs because only a 132-char limit is required there.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Reviewed-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Release notes: https://www.videolan.org/developers/vlc-branch/NEWS
Fixes the following security bugs:
* Fix a buffer overflow in the MKV demuxer (CVE-2019-14970)
* Fix a read buffer overflow in the avcodec decoder (CVE-2019-13962)
* Fix a read buffer overflow in the FAAD decoder
* Fix a read buffer overflow in the OGG demuxer (CVE-2019-14437, CVE-2019-14438)
* Fix a read buffer overflow in the ASF demuxer (CVE-2019-14776)
* Fix a use after free in the MKV demuxer (CVE-2019-14777, CVE-2019-14778)
* Fix a use after free in the ASF demuxer (CVE-2019-14533)
* Fix a couple of integer underflows in the MP4 demuxer (CVE-2019-13602)
* Fix a null dereference in the dvdnav demuxer
* Fix a null dereference in the ASF demuxer (CVE-2019-14534)
* Fix a null dereference in the AVI demuxer
* Fix a division by zero in the CAF demuxer (CVE-2019-14498)
* Fix a division by zero in the ASF demuxer (CVE-2019-14535)
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
Security: when using HTTP/2 a client might cause excessive memory
consumption and CPU usage (CVE-2019-9511, CVE-2019-9513,
CVE-2019-9516).
For details, see the advisory:
https://mailman.nginx.org/pipermail/nginx-announce/2019/000249.html
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit was pushed accidentally, it was not yet ready for prime
time. A better way to implement it was proposed.
In addition, it still introduces a circular dependency: systemd ->
polkit -> libglib2 -> util-linux -> systemd
This reverts commit 335c77b667.
uClibc doesn't build with the upstream binutils 2.32.x and gcc or1k
port due to the following error:
LD libuClibc-1.0.31.so
/opt/openrisc--uclibc--bleeding-edge-1/lib/gcc/or1k-buildroot-linux-uclibc/9.2.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
libc/libc_so.a(or1k_clone.os): pc-relative relocation against dynamic symbol
__syscall_error
See:
https://gitlab.com/kubu93/toolchains-builder/-/jobs/270854456
This error message come from a new check in binutils 2.32.x:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=f2c1801f6255a3f9f483ae2f07c7d7da0ddae4af
This issue has been reported on the uClibc-ng mailing list:
https://mailman.uclibc-ng.org/pipermail/devel/2019-August/001885.html
Since gcc 9.1 needs binutils 2.32.x or later to build successfully for
or1k, there is no binutils version left that can build gcc 9.1 and
uClibc.
For now, disable uClibc if gcc 9.1 is used for or1k.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Waldemar Brodkorb <mail@waldemar-brodkorb.de>
[Arnout: invert the logic, like in the rest of the file]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
With binutils 2.30.x or 2.31.x, the assembler doesn't
support the code generated by gcc 9.1:
Error: junk at end of line `l.movhi r17,gotoffha(.LC0)'
gotoffha is supported by binutils since version 2.32 [1].
It was added by the ork1 gcc port merged into gcc 9.x [2].
So, for or1k we can select gcc 9.x only if binutils 2.32
(or later) is selected.
Tested using qemu_or1k_defconfig and selecting musl libc,
binutils 2.32 and gcc 9.1.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=1c4f3780f7d939402cfe555007ebff45c8e38951
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d61fdfe71cfd42aa6454f2267a48c97820918fe3
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Waldemar Brodkorb <mail@waldemar-brodkorb.de>
[Arnout: invert the logic, like in the rest of the file]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
