We can use use `stdenv.hostPlatform.isStatic` instead, and move the
logic per package. The least opionated benefit of this is that it makes
it much easier to replace packages with modified ones, as there is no
longer any issue of overlay order.
CC @FRidh @matthewbauer
1. Gnumeric has unbalanced XML tags in its doc translations.
2. itstool's XML error handler tries to print this error with context.
3. libxml2's context snipper treats the data as bytes, not UTF-8.
4. python3Packages.libxml2 casts the context to a UTF-8 Python string.
5. itstool dereferences a null pointer.
This patch intervenes at #4.
In https://bugzilla.gnome.org/show_bug.cgi?id=789714#c4 , upstream
suggests that intervening at #3 would be better -- that each of the four
copies of xmlParserPrintFileContextInternal() have four additional UTF-8
problems, one of which is that the caret indicator ought to count
"unicode characters" not bytes. But to position a caret correctly, a
character count is not sufficient -- this would need to use icu's BiDi
logic (with fallback to doing something wrong when libxml2 is configured
not to use icu) -- which makes a 'correct' fix a much larger project
than this simple band-aid.
The static output should only get created when both enableShared and
enableStatic are set. Otherwise there would be libraries missing from
the main output when enableShared = false & enableStatic = true. This
can cause issues in some packages that don’t know about libxml2’s
static output.
(cherry picked from commit 2bd6bb0a4bf21005d8877c735709cd21d22e05bd)
(cherry picked from commit 1421a39c1e62584d346185ad49484b11b7703dc1)
Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 2.9.8 in filename of file in /nix/store/cjycf1wx5a5l22a9kwhpnnh2h9i7pahk-libxc-4.0.4
This should solve CVE-2016-5131 and some other bugs, but not what Suse
calls CVE-2016-9597: https://bugzilla.suse.com/show_bug.cgi?id=1017497
The bugzilla discussion seems to indicate that the CVE is referenced
incorrectly and only shows reproducing when using command-line flags
that are considered "unsafe".
CVE-2016-9318 also remains unfixed, as I consider their reasoning OK:
https://lwn.net/Alerts/714411/
/cc #22826.
