gst-plugins-bad:
From the Arch Linux advisory:
- CVE-2017-5843 (arbitrary code execution): A double-free issue has
been found in gstreamer before 1.10.3, in
gst_mxf_demux_update_essence_tracks.
- CVE-2017-5848 (denial of service): An out-of-bounds read has been
found in gstreamer before 1.10.3, in gst_ps_demux_parse_psm.
More: https://lwn.net/Vulnerabilities/713772/
gst-plugins-base:
From the Arch Linux advisory:
- CVE-2017-5837 (denial of service): A floating point exception issue
has been found in gstreamer before 1.10.3, in
gst_riff_create_audio_caps.
- CVE-2017-5839 (denial of service): An endless recursion issue
leading to stack overflow has been found in gstreamer before 1.10.3,
in gst_riff_create_audio_caps.
- CVE-2017-5842 (arbitrary code execution): An off-by-one write has
been found in gstreamer before 1.10.3, in
html_context_handle_element.
- CVE-2017-5844 (denial of service): A floating point exception issue
has been found in gstreamer before 1.10.3, in
gst_riff_create_audio_caps.
More: https://lwn.net/Vulnerabilities/713773/
gst-plugins-good:
From the Arch Linux advisory:
- CVE-2016-10198 (denial of service): An invalid memory read flaw has
been found in gstreamer before 1.10.3, in
gst_aac_parse_sink_setcaps.
- CVE-2016-10199 (denial of service): An out of bounds read has been
found in gstreamer before 1.10.3, in qtdemux_tag_add_str_full.
- CVE-2017-5840 (denial of service): An out-of-bounds read has been
found in gstreamer before 1.10.3, in qtdemux_parse_samples.
- CVE-2017-5841 (denial of service): An out-of-bounds read has been
found in gstreamer before 1.10.3, in gst_avi_demux_parse_ncdt.
- CVE-2017-5845 (denial of service): An out-of-bounds read has been
found in gstreamer before 1.10.3, in gst_avi_demux_parse_ncdt.
More: https://lwn.net/Vulnerabilities/713774/
gst-plugins-ugly:
From the Arch Linux advisory:
- CVE-2017-5846 (denial of service): An out-of-bounds read has been
found in gstreamer before 1.10.3, in
gst_asf_demux_process_ext_stream_props.
- CVE-2017-5847 (denial of service): An out-of-bounds read has been
found in gstreamer before 1.10.3, in
gst_asf_demux_process_ext_content_desc.
More: https://lwn.net/Vulnerabilities/713775/
gstreamer:
From the Arch Linux advisory:
An out of bounds read has been found in gstreamer before 1.10.3, in
gst_date_time_new_from_iso8601_string.
More: https://lwn.net/Vulnerabilities/713776/
This will need more patching to work properly (especially for python
builds), but I've been able to convince it to build some simple java and
scala projects in its current form so I figured I'd spread it.
-split-sections replaced -split-objs with following upsides:
1) -split-objs adds considerable overhead to compile time
2) combined with stripping, it causes issues when cross-compiling
For upstream see https://ghc.haskell.org/trac/ghc/ticket/8405
This is supported only for Linux/Windows using ld linker.
GHC master also turns on -split-sections by default.
Example using stack:
Without splitting
$ du /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2
4 /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2/share/bash-completion/completions
4 /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2/share/bash-completion
4 /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2/share
23416 /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2/bin
23420 /nix/store/5paayhibayr73zqfaj458g4k4mv108jn-stack-1.3.2
With -split-objs
$ du /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2
20632 /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2/bin
4 /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2/share/bash-completion/completions
4 /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2/share/bash-completion
4 /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2/share
20636 /nix/store/fypymm529adpx71gdzm0851xz42wdbz0-stack-1.3.2
With -split-sections
$ du /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2
4 /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2/share/bash-completion/completions
4 /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2/share/bash-completion
4 /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2/share
20672 /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2/bin
20676 /nix/store/40l6krinx1zx41lr87c4m12hxj4ldf3x-stack-1.3.2
Note: you currently need following overrides to build stack on 802:
vector-algorithms = dontCheck super.vector-algorithms;
path-io = doJailbreak super.path-io;
stack = doJailbreak super.stack;
Note: Should also work on GHC 8.0.1, but I'm being careful here.
We could backport later on.
Since the update of imagemagick in
5e753c1a65 there are certain test cases
which now unexpectly succeed and in turn cause the whole build to fail.
So in order to prevent this from happening let's skip those tests
properly instead of running them and expect them to fail.
Tested by building pythonPackages.pyocr on x86_64-linux.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Tested via building the linux_testing attribute only, not in production.
Verified unpacked tarball with GnuPG:
gpg: Signature made Mon 06 Feb 2017 12:21:50 AM CET
gpg: using RSA key 79BE3E4300411886
gpg: Good signature from "Linus Torvalds <torvalds@linux-foundation.org>" [unknown]
Primary key fingerprint: ABAF 11C6 5A29 70B1 30AB E3C4 79BE 3E43 0041 1886
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Upstream bug: https://bugs.ghostscript.com/show_bug.cgi?id=697457
A new release containing this fix is expected in march; until then,
apply patch from upstream. Note that there have been essentially no
changes between 0.13 and this patch.
The most recent version on the sourceforge page is 0.11 which is quite
old; the official upstream site has 0.13; judging by the commit delta,
there've been quite a few bug fixes etc since 0.11.
The first release in the 4.9 branch.
I've also migrated my update scripts to SHA-512 so that'll
be the hash of choice for grsec packages going forward.
The callCabal2nix function cannot reliably determine the appropriate "name" for
the package it's processing. Attempts to derive this information have led to
plenty of evaluation errors, and so I'd like to go for the obvious and reliable
solution now and let the caller specify that bit of information.
Here is an example that demonstrates how to use callCabal2nix.
let
pkgs = import <nixpkgs> {};
src = pkgs.fetchFromGitHub {
owner = "gtk2hs";
repo = "gtk2hs";
rev = "eee61d84edf1dd44f8d380d7d7cae2405de50124";
sha256 = "12i53grimni0dyjqjydl120z5amcn668w4pfhl8dxscjh4a0l5nb";
};
in
pkgs.haskellPackages.callCabal2nix "gtkhs-tools" "${src}/tools" {}
This fixes the "sliding window" principle:
0. Run packages: build = native; host = foreign; target = foreign;
1. Build packages: build = native; host = native; target = foreign;
2. Vanilla packages: build = native; host = native; target = native;
3. Vanilla packages: build = native; host = native; target = native;
n+3. ...
Each stage's build dependencies are resolved against the previous stage,
and the "foreigns" are shifted accordingly. Vanilla packages alone are
built against themsevles, since there are no more "foreign"s to shift away.
Before, build packages' build dependencies were resolved against
themselves:
0. Run packages: build = native; host = foreign; target = foreign;
1. Build packages: build = native; host = native; target = foreign;
2. Build packages: build = native; host = native; target = foreign;
n+2. ...
This is wrong because that principle is violated by the target
platform staying foreign.
This will change the hashes of many build packages and run packages, but
that is OK. This is an unavoidable cost of fixing cross compiling.
The cross compilation docs have been updated to reflect this fix.
