The autoupgrade service defined in `system.autoUpgrade`
(`nixos/modules/installer/tools/auto-upgrade.nix`) doesn't have `su` in
its path and thus yields a warning during the `daemon-reload`.
Specifying the absolute path fixes the issue.
Fixes#47648
* Version 4.01.17 works fine for me on NixOS, driving both a Samsung ML-2165w
and a Samsung ML-2510 printer successfully.
* Version 4.00.39 is broken. The build shows errors, but doesn't abort. The
generated binaries don't work, because they are lacking rpaths to their
library dependencies.
* Renamed old default.nix file to 1.00.37.nix. That version wasn't the default
and it feels like a bad idea to mix versioned and unversioned file names in
the same directory.
This update bumps the package to the latest stable version containing a
few security fixes:
- CVE-2018-12386: Type confusion in JavaScript
A vulnerability in register allocation in JavaScript can lead to type
confusion, allowing for an arbitrary read and write. This leads to
remote code execution inside the sandboxed content process when
triggered.
- CVE-2018-12387
A vulnerability where the JavaScript JIT compiler inlines
Array.prototype.push with multiple arguments that results in the stack
pointer being off by 8 bytes after a bailout. This leaks a memory
address to the calling function which can be used as part of an
exploit inside the sandboxed content process.
Source: https://www.mozilla.org/en-US/security/advisories/mfsa2018-24/
This update bumps the package to the latest stable version containing a
few security fixes:
- CVE-2018-12386: Type confusion in JavaScript
A vulnerability in register allocation in JavaScript can lead to type
confusion, allowing for an arbitrary read and write. This leads to
remote code execution inside the sandboxed content process when
triggered.
- CVE-2018-12387
A vulnerability where the JavaScript JIT compiler inlines
Array.prototype.push with multiple arguments that results in the stack
pointer being off by 8 bytes after a bailout. This leaks a memory
address to the calling function which can be used as part of an
exploit inside the sandboxed content process.
Source: https://www.mozilla.org/en-US/security/advisories/mfsa2018-24/
This update bumps the package to the latest stable version containing a
few security fixes:
- CVE-2018-12386: Type confusion in JavaScript
A vulnerability in register allocation in JavaScript can lead to type
confusion, allowing for an arbitrary read and write. This leads to
remote code execution inside the sandboxed content process when
triggered.
- CVE-2018-12387
A vulnerability where the JavaScript JIT compiler inlines
Array.prototype.push with multiple arguments that results in the stack
pointer being off by 8 bytes after a bailout. This leaks a memory
address to the calling function which can be used as part of an
exploit inside the sandboxed content process.
Source: https://www.mozilla.org/en-US/security/advisories/mfsa2018-24/
From commit b63f65aea0:
I used tmpfiles.d instead of activation snippets to create the logs.
It's good enough for upstream and other distros; it's probably good
enough for us.
The "reboot-wtmp" subtest fails because it it assumes that there is a
reboot record even on the initial boot. This is only the case if wtmp is
created within the activation script, but the implementation now uses
tmpfiles.d, so the creation of the file is done at a much later stage.
Apart from that, if you think about the state after the installation as
"first boot", using the term "reboot" wouldn't probably make sense
either.
So in our subtest, we now reboot the machine and check the wtmp record
afterwards as we did before.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra, @jameysharp, @Mic92
darwin.security_tool is currently broken in Mojave. See issue #45042
for more info. Our security_tool stuff comes from 10.9 so I suspect
that it needs an update.
Here I am putting in a hack to get things working again. This uses the
system provided security binary at /usr/bin/security to avoid the
issue in Haskell’s x509-system package. Unfortunately, this will break
with the sandbox. I am also working on a proper fix, but this requires
updating lots of Apple stuff (and also copumpkin’s new CF). You can
follow the progress on this branch:
https://github.com/matthewbauer/nixpkgs/tree/xcode-security
This commit should be backported to release-18.03 and release-18.09.
/cc @copumpkin @lnl7 @pikajude
