Leo Famulari <l...@famulari.name> skribis: > On Thu, Nov 02, 2017 at 05:22:34PM -0400, Marius Bakke wrote: >> commit 1df4f5c919937b60bfb21ac2a60d8f0a6737c421 >> Author: Marius Bakke <mba...@fastmail.com> >> Date: Thu Nov 2 22:11:25 2017 +0100 >> >> gnu: openssl@1.0: Replace with 1.0.2m [fixes CVE-2017-3735, >> CVE-2017-2736]. >> >> * gnu/packages/tls.scm (openssl)[replacement]: New field. >> (openssl-1.0.2m): New public variable. > > [...] > >> +;; Fixes CVE-2017-3735 and CVE-2017-3736. >> +;; See <https://www.openssl.org/news/cl102.txt>. >> +(define-public openssl-1.0.2m > > In the early days of recursive grafts, Mark replaced libgcrypt with a > public variable, and it was resolved non-deterministically. We ended up > having to make the replacement private: > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=69aa6e0995b55a38d5ce174602a107645be726d5 > > I remember doing something like this and getting different results > randomly: > > $ while true; do guix build --source openssl@1.0.2 ;done > guix build: warning: ambiguous package specification `openssl@1.0.2' > guix build: warning: choosing openssl@1.0.2m from gnu/packages/tls.scm:402:2 > /gnu/store/3hsffv38zzn3pafzr3g4x6mwqmxcmnr5-openssl-1.0.2m.tar.xz > [...] > > But now it seems to consistently pick the correct package. > > Did the implementation change to ensure that it does the right thing?
Under the hood package lookup in this case uses ‘find-packages-by-name’ from (gnu packages). That thing builds a lookup table (a vhash) by iterating over the packages with ‘fold-packages’; in turn it uses ‘all-modules’, which is deterministic (thanks to ‘scandir*’), and ‘fold-module-public-variables’, which *could* be non-deterministic due to ‘module-map’ I think (because it iterates over a hash table.) However, ‘find-packages-by-name’ sorts entries by version, so in this specific case, we’ll always pick 1.0.2m over 1.0.2l. Non-determinism can occur if we have two or more packages with the exact same version string. Thanks, Ludo’.
