To fix the horrendous glibc bug [1] on my system, without rebuilding my whole system, I just rebuilt glibc with the fix from master. Then i just softlinked older versions of glibc-2.21 to the fixed one, by doing the following in a zsh:
# uses zsh/files to be able to use mv and ls # while glib is being moved around > zmodload zsh/files > VULNERABLE=( /nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21 /nix/store/y8scgsh8warhiy3pl39mqxyxphybcy7p-glibc-2.21 /nix/store/jlmb88f5hgigbmc3c74ynxgn3frlzxkr-glibc-2.21 /nix/store/n2wxp513rr00f6hr2dy0waqahns49dch-glibc-2.21 /nix/store/5lbwvhljfp5k3dpyj0w1waj2qvyfkph8-glibc-2.21 ) > FIXED=/nix/store/3xnbb8hkzv8nmndssknx413sd217bj56-glibc-2.21 > mount -o remount,rw /nix/store > for glibc in $VULNERABLE; do zf_mv $glib $glib.bkp zf_ln -s $FIXED $glib done The resulting system just survived a reboot and seems to work just fine. I can't reproduce the POC for the vulnerability on it [2] Of course, this is not a total solution (only for programs, dynamically linking glibc), but it buys time until the rebuild is through. Therefore, I'd like to see this approach supported by nix as a hotfixing system, for cases where security concerns weigh more than concerns about binary compatibility. Nix could track designated hotfix derivations, that promise to uphold binary compatibility, and could even use bspatch to distribute them. [1] http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/ [2] https://github.com/fjserna/CVE-2015-7547
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
