Release 15.09 #22
Open
Release 15.09 #22
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
davmail: 4.7.0 -> 4.7.1
Also add missing dependency: goPackages.hmacauth: init at 20151013 (cherry picked from commit 23beba4)
Kombu amqp update backport
(cherry picked from commit 50355a2)
(cherry picked from commit 57155e0)
(cherry picked from commit 45705d5)
(cherry picked from commit df02ed5)
(cherry picked from commit e24211d)
(cherry picked from commit fe287de)
(cherry picked from commit 12a6fc7)
(cherry picked from commit a9abdc8)
(cherry picked from commit 85f5394)
(cherry picked from commit 50a842f)
(cherry picked from commit 66cddef)
(cherry picked from commit 4e97292)
This is a regression introduced by merging the EBS and S3 images. The EBS images had a special marker /.ebs to prevent the initrd from using ephemeral storage for the unionfs, but this marker was missing in the consolidated image. The fix is to check the file ami-manifest-path on the metadata server to see if we're an S3-based instance. This does require networking in the initrd. Issue #12613. (cherry picked from commit 06731df)
(cherry picked from commit 7b772ae)
(cherry picked from commit 78956c7)
This fixes CVE-2016-0755: https://curl.haxx.se/docs/adv_20160127A.html Mostly cherry-picked from 0876a44. vcunat stripped it to minimum needed to get the security update.
…path (cherry picked from commit 5c20877)
(cherry picked from commit e4728dd)
(cherry picked from commit 3b6b479) Signed-off-by: Robin Gloster <[email protected]>
…for KDE (cherry picked from commit ae662cd)
Probably missed a few. Also adding xauth to the system path (it was already in the closure). (cherry picked from commit 9153d8e)
(cherry picked from commit a42698d)
Needed for newer 'cryptography', which is needed to fix build against latest openssl. Based on 4b23328 ("buildPythonPackage: fix more wheels failures").
(cherry picked from commit baf7f98) [Bjørn: some tweaks needed to apply to release-15.09]
Unfortunately, pkill doesn't distinguish between kernel and user space processes, so we need to make sure we don't accidentally kill kernel threads. Normally, a kernel thread ignores all signals, but there are a few that do. A quick grep on the kernel source tree (as of kernel 4.6.0) shows the following source files which use allow_signal(): drivers/isdn/mISDN/l1oip_core.c drivers/md/md.c drivers/misc/mic/cosm/cosm_scif_server.c drivers/misc/mic/cosm_client/cosm_scif_client.c drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c drivers/staging/rtl8188eu/core/rtw_cmd.c drivers/staging/rtl8712/rtl8712_cmd.c drivers/target/iscsi/iscsi_target.c drivers/target/iscsi/iscsi_target_login.c drivers/target/iscsi/iscsi_target_nego.c drivers/usb/atm/usbatm.c drivers/usb/gadget/function/f_mass_storage.c fs/jffs2/background.c fs/lockd/clntlock.c fs/lockd/svc.c fs/nfs/nfs4state.c fs/nfsd/nfssvc.c While not all of these are necessarily kthreads and some functionality may still be unimpeded, it's still quite harmful and can cause unexpected side-effects, especially because some of these kthreads are storage-related (which we obviously don't want to kill during bootup). During discussion at #15226, @dezgeg suggested the following implementation: for pid in $(pgrep -v -f '@'); do if [ "$(cat /proc/$pid/cmdline)" != "" ]; then kill -9 "$pid" fi done This has a few downsides: * User space processes which use an empty string in their command line won't be killed. * It results in errors during bootup because some shell-related processes are already terminated (maybe it's pgrep itself, haven't checked). * The @ is searched within the full command line, not just at the beginning of the string. Of course, we already had this until now, so it's not a problem of his implementation. I posted an alternative implementation which doesn't suffer from the first point, but even that one wasn't sufficient: for pid in $(pgrep -v -f '^@'); do readlink "/proc/$pid/exe" &> /dev/null || continue echo "$pid" done | xargs kill -9 This one spawns a subshell, which would be included in the processes to kill and actually kills itself during the process. So what we have now is even checking whether the shell process itself is in the list to kill and avoids killing it just to be sure. Also, we don't spawn a subshell anymore and use /proc/$pid/exe to distinguish between user space and kernel processes like in the comments of the following StackOverflow answer: http://stackoverflow.com/a/12231039 We don't need to take care of terminating processes, because what we actually want IS to terminate the processes. The only point where this (and any previous) approach falls short if we have processes that act like fork bombs, because they might spawn additional processes between the pgrep and the killing. We can only address this with process/control groups and this still won't save us because the root user can escape from that as well. Signed-off-by: aszlig <[email protected]> Fixes: #15226
This is a regression test for #15226, so that the test will fail once we accidentally kill one or more of the md kthreads (aka: if safe mode is enabled). Signed-off-by: aszlig <[email protected]>
We already have a small regression test for #15226 within the swraid installer test. Unfortunately, we only check there whether the md kthread got signalled but not whether other rampaging processes are still alive that *should* have been killed. So in order to do this we provide multiple canary processes which are checked after the system has booted up: * canary1: It's a simple forking daemon which just sleeps until it's going to be killed. Of course we expect this process to not be alive anymore after boot up. * canary2: Similar to canary1, but tries to mimick a kthread to make sure that it's going to be properly killed at the end of stage 1. * canary3: Like canary2, but this time using a @ in front of its command name to actually prevent it from being killed. * kcanary: This one is a real kthread and it runs until killed, which shouldn't be the case. Tested with and without 67223ee and everything works as expected, at least on my machine. Signed-off-by: aszlig <[email protected]>
We don't want to push out a channel update whenever this test fails, because that might have unexpected and confused side effects and it *really* means that stage 1 of our boot up is broken. Signed-off-by: aszlig <[email protected]>
As @edolstra pointed out that the kernel module might be painful to maintain. I strongly disagree because it's only a small module and it's good to have such a canary in the tests no matter how the bootup process looks like, so I'm going the masochistic route and try to maintain it. If it *really* becomes too much maintenance burden, we can still drop or disable kcanary. Signed-off-by: aszlig <[email protected]>
Merges pull request #15275: This addresses #15226 and fixes killing of processes before switching from the initrd to the real root. Right now, the pkill that is issued not only kills user space processes but also sends a SIGKILL to kernel threads as well. Usually these threads ignore signals, but some of these processes do handle signals, like for example the md module, which happened in #15226. It also adds a small check for the swraid installer test and a standalone test which checks on just that problem, so in the future this shouldn't happen again. This has been acked by @edolstra on IRC. The reason I'm merging this to 15.09 is that this branch fixes #15226 and thus also fixes mdraid setups out there. Tested using the boot-stage1.nix NixOS test against release-15.09.
Cleanups are mostly stylistic, like putting src more to the top (to make sure it won't be missed on updates of the version attribute) or using mkdir -p instead of ensureDir. The most significant change here is that we update the package to 1.8.0-jumbo-1, which is the latest tag available and contains community updates which were already in openwall/john@93f061bc41652. We're now also using fetchurl to ensure that we don't need to clone the whole repository and keep download times low. And the derivation name is now "john" instead of "JohnTheRipper", because most users would expect "nix-env -i john" to work. Signed-off-by: aszlig <[email protected]> (cherry picked from commit 2a1bf2a)
It prevents john from running with older CPUs such as Core2Duo and gives an illegal hardware instruction error on these CPUs. Signed-off-by: aszlig <[email protected]> (cherry picked from commit cf4e2c4)
So far it was only possible to run john if you've either copied over the default configuration over to ~/.john and substitute $JOHN with the right path or set $JOHN to the store path directly. Both methods are not really a very good user experience, so we're now patching in the resulting paths into the default rules/configurations. This also splits off configuration files into $out/etc/john instead of putting everything into $out/share/john and now also properly installs the auxiliary programs into $out/bin. Closes #8792. Signed-off-by: aszlig <[email protected]> Reported-by: devhell <"^"@regexmail.net> Cc: @offlinehacker (cherry picked from commit 902bcf1)
I've built this a lot of times on different machines without getting compile errors, so I'd assume this to be safe. Of course, the compile time is very small in comparison to bigger packages but it's still an annoyance to wait for up to a few minutes, especially during development. Signed-off-by: aszlig <[email protected]> (cherry picked from commit 37429a2)
(cherry picked from commit 977cd5d)
The current URL is broken, upstream has moved the download from .../files/ to .../files_legacy/. But after fixing that, starting hashcat results in: $ ./result/bin/hashcat ERROR: this copy of hashcat is outdated. Get a more recent version. So just update to latest. New releases are on github, the license is now MIT and there are build system changes. (cherry picked from commit 800042b)
(cherry picked from commit f768098)
Release announcement, 2016-01-30: https://www.sigrok.org/blog/major-sigrok-releases-libsigrok-libsigrokdecode-sigrok-cli-pulseview I first tried updating the projects in separate commits. But later I found cyclic dependencies, that would break git bisect, so I ended up squashing the commits: * libsigrok: 0.3.0 -> 0.4.0 Enable building libsigrokcxx.so, the C++ bindings for libsigrok, by adding doxygen, glibmm and python as build deps. This is needed for Pulseview >= 0.3.0. Also update the firmware (sigrok-firmware-fx2lafw) while at it. * libsigrokdecode: 0.3.0 -> 0.4.0 * sigrok-cli: 0.5.0 -> 0.6.0 * pulseview: 0.2.0 -> 0.3.0 New dependency: glibmm (due to libsigrokcxx.pc from libsigrok). Note that collectd is incompatible with the new libsigrok release, so I let it use the old one (0.3.0). (cherry picked from commit 300e495)
(cherry picked from commit cade2f3)
(cherry picked from commit 45a14c8) I just tested it builds on x86_64-linux.
This addresses the following security fixes: * High CVE-2016-1667: Same origin bypass in DOM. Credit to Mariusz Mlynski. * High CVE-2016-1668: Same origin bypass in Blink V8 bindings. Credit to Mariusz Mlynski. * High CVE-2016-1669: Buffer overflow in V8. Credit to Choongwoo Han. * Medium CVE-2016-1670: Race condition in loader. Credit to anonymous. * Medium CVE-2016-1671: Directory traversal using the file scheme on Android. Credit to Jann Horn. See: http://googlechromereleases.blogspot.com/2016/05/stable-channel-update.html Signed-off-by: Scott R. Parish <[email protected]> Tested-by: aszlig <[email protected]> Closes: #15446 Signed-off-by: aszlig <[email protected]> (cherry picked from commit 5ebf20d)
Overview of the updated versions: beta: 50.0.2661.49 -> 51.0.2704.47 dev: 51.0.2693.2 -> 52.0.2729.3 It has been a while since we had a major Chromium update that compiled and worked without troubles, but version 52 builds and the VM tests are successful as well: https://headcounter.org/hydra/eval/320335 Signed-off-by: aszlig <[email protected]> (cherry picked from commit ad2c8d3) Reason: 50.0.2661.102 fixes a bunch of security vulnerabilities and we want to have them fixed in beta/dev as well.
This is the original pull request plus some commits from me to bring all channels to the latest versions, because the fixed security vulnerabilites might not be fixed in the dev version we had before. I've tested the whole changeset on my Hydra at: https://headcounter.org/hydra/eval/322006 Thanks to @srp for the initial commit and thus implicitly also for the security notice. Cc: @abbradar (backported from commit b5f95a5) Reason: Lots of security fixes (see e2d067d)
stable 51.0.2704.63 => 51.0.2704.103 beta 51.0.2704.63 => 52.0.2743.41 dev 52.0.2743.10 => 53.0.2767.4 This addresses 15 security fixes, including: * High CVE-2015-1696: Cross-origin bypass in Extension bindings. Credit to anonymous. * High CVE-2015-1697: Cross-origin bypass in Blink. Credit to Mariusz Mlynski. * Medium CVE-2016-1698: Information leak in Extension bindings. Credit to Rob Wu. * Medium CVE-2016-1699: Parameter sanitization failure in DevTools. Credit to Gregory Panakkal. * Medium CVE-2016-1700: Use-after-free in Extensions. Credit to Rob Wu. * Medium CVE-2016-1701: Use-after-free in Autofill. Credit to Rob Wu. * Medium CVE-2016-1702: Out-of-bounds read in Skia. Credit to cloudfuzzer. See: http://googlechromereleases.blogspot.com/2016/06/stable-channel-update.html (cherry picked from commit 1f1f0f0) Reason: 18 Security fixes for the stable channel.
(cherry picked from commit 516f331)
(cherry picked from commit cc0b3bb)
(cherry picked from commit c5b96ca)
(cherry picked from commit 800a379)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.