Re: `guix pull` over HTTPS

[ng0 <contact.ng0@cryptolab.net>]

On 17-02-10 23:43:45, Marius Bakke wrote:
> Ludovic Courtès <ludo@gnu.org> writes:
> 
> > Marius Bakke <mbakke@fastmail.com> skribis:
> >
> >> Ludovic Courtès <ludo@gnu.org> writes:
> >>
> >>> Leo Famulari <leo@famulari.name> 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.

I am relatively sure that LE would let its now very large user base know
in advance when a change like a new intermediate CA is being introduced,
but if we are really in doubt we could ask LE themselves.

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/