Re: `guix pull` over HTTPS

[Ludovic Courtès]

Marius Bakke <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:
>
>> Marius Bakke <address@hidden> skribis:

[...]

>>> 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.

Yeah, sounds fragile.

> 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.

That sounds more reasonable to me.  Do you know what it would take to
get the whole LE chain in such a package?  Would you like to give it a
try?

Thanks,
Ludo’.