guix-devel
[Top][All Lists]
Advanced

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

Re: `guix pull` over HTTPS


From: Marius Bakke
Subject: Re: `guix pull` over HTTPS
Date: Fri, 10 Feb 2017 23:43:45 +0100
User-agent: Notmuch/0.23.5 (https://notmuchmail.org) Emacs/25.1.1 (x86_64-unknown-linux-gnu)

Ludovic Courtès <address@hidden> writes:

> Marius Bakke <address@hidden> skribis:
>
>> Ludovic Courtès <address@hidden> writes:
>>
>>> Leo Famulari <address@hidden> skribis:
>>>
>
> [...]
>
>>> 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
>
> All good points.  Well, I guess there’s not much we can do?

I think pinning the public key could work, if the Savannah
administrators are aware of it. But we'd need a reliable fallback
mechanism in case the private key needs to be updated.

I think having a separate 'le-certs' package that can verify the Lets
Encrypt chain sounds like the easiest option. Presumably new
intermediates etc will be known well in advance.

Attachment: signature.asc
Description: PGP signature


reply via email to

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