guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 01/02: gnu: address@hidden: Replace with 1.0.2m [fixes CVE-2017-3735


From: Ludovic Courtès
Subject: Re: 01/02: gnu: address@hidden: Replace with 1.0.2m [fixes CVE-2017-3735, CVE-2017-2736].
Date: Tue, 28 Nov 2017 17:29:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Leo Famulari <address@hidden> skribis:

> On Thu, Nov 02, 2017 at 05:22:34PM -0400, Marius Bakke wrote:
>> commit 1df4f5c919937b60bfb21ac2a60d8f0a6737c421
>> Author: Marius Bakke <address@hidden>
>> Date:   Thu Nov 2 22:11:25 2017 +0100
>> 
>>     gnu: address@hidden: 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 address@hidden ;done
> guix build: warning: ambiguous package specification address@hidden'
> guix build: warning: choosing address@hidden 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’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]