[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.
signature.asc
Description: PGP signature
- `guix pull` over HTTPS, Leo Famulari, 2017/02/09
- Re: `guix pull` over HTTPS, Leo Famulari, 2017/02/09
- Re: `guix pull` over HTTPS, Ludovic Courtès, 2017/02/10
- Re: `guix pull` over HTTPS, Marius Bakke, 2017/02/10
- Re: `guix pull` over HTTPS, Ludovic Courtès, 2017/02/10
- Re: `guix pull` over HTTPS,
Marius Bakke <=
- Re: `guix pull` over HTTPS, ng0, 2017/02/10
- Re: `guix pull` over HTTPS, Ludovic Courtès, 2017/02/11
- Re: `guix pull` over HTTPS, Leo Famulari, 2017/02/11
- Re: `guix pull` over HTTPS, Ricardo Wurmus, 2017/02/11
- Re: `guix pull` over HTTPS, Ludovic Courtès, 2017/02/12
- Re: `guix pull` over HTTPS, Leo Famulari, 2017/02/28
- Re: `guix pull` over HTTPS, Marius Bakke, 2017/02/28
- Re: `guix pull` over HTTPS, Leo Famulari, 2017/02/28
- Re: `guix pull` over HTTPS, Marius Bakke, 2017/02/28
- Re: `guix pull` over HTTPS, Marius Bakke, 2017/02/28