Re: `guix pull` over HTTPS

[Marius Bakke <mbakke@fastmail.com>]

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

Ludovic Courtès <ludo@gnu.org> writes:

> Leo Famulari <leo@famulari.name> skribis:
>
>> On Thu, Feb 09, 2017 at 04:55:12PM +0100, Leo Famulari wrote:
>>> Does anyone have any specific concerns or advice about changing the
>>> value of %snapshot-url in (guix scripts pull) to use the HTTPS URL?
>>> Should the change be that simple, or should we do more?
>>
>> While testing, I realized that an X.509 certificate store is not a
>> standard feature of GuixSD, so using Savannah's HTTPS URL will not work
>> in all cases.
>>
>> SSL_CERT_FILE and SSL_CERT_DIR appear to be set unconditionally in (gnu
>> system operating-system-environment-variables), so it's not enough to
>> test that they are set in order to decide which protocol to download the
>> Guix source code with.
>>
>> Any advice on how to proceed?
>
> Initially, I didn’t want to have ‘nss-certs’ in ‘%base-packages’ or
> anything like that, on the grounds that the whole X.509 CA story is
> completely broken IMO.  I wonder if we should revisit that, on the
> grounds that “it’s better than nothing.”
>
> The next question is what to do with foreign distros, and whether we
> should bundle ‘nss-certs’ in the binary tarball, which is not exciting.
>
> Alternately we could have a package that provides only the Let’s Encrypt
> certificate chain, if that’s what Savannah uses.
>
> Thoughts?

If the private key used on https://git.savannah.gnu.org/ is static, one
option would be to "pin" the corresponding public key. However, some LE
clients also rotate the private key when renewing, so we'd need to ask
SV admins. And also receive notices in advance if the key ever changes.

Pinning the intermediate CAs might work, but what to do when the
certificate is signed by a new intermediate (which may happen[0])? How
to deliver updates to users with old certs?

See: https://www.owasp.org/index.php/Pinning_Cheat_Sheet and
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

..for quick and long introductions, respectively.

[0] https://community.letsencrypt.org/t/hpkp-best-practices-if-you-choose-to-implement/4625?source_topic_id=2450

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