Re: 01/02: gnu: openssl@1.0: Replace with 1.0.2m [fixes CVE-2017-3735, CVE-2017-2736].

Re: 01/02: gnu: openssl@1.0: Replace with 1.0.2m [fixes CVE-2017-3735, CVE-2017-2736].

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

On Thu, Nov 02, 2017 at 05:22:34PM -0400, Marius Bakke wrote:
> commit 1df4f5c919937b60bfb21ac2a60d8f0a6737c421
> Author: Marius Bakke <mbakke@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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 01/02: gnu: openssl@1.0: Replace with 1.0.2m [fixes CVE-2017-3735, CVE-2017-2736].

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> On Thu, Nov 02, 2017 at 05:22:34PM -0400, Marius Bakke wrote:
>> commit 1df4f5c919937b60bfb21ac2a60d8f0a6737c421
>> Author: Marius Bakke <mbakke@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’.