[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: `guix pull` over HTTPS
From: |
ng0 |
Subject: |
Re: `guix pull` over HTTPS |
Date: |
Fri, 10 Feb 2017 22:52:49 +0000 |
On 17-02-10 23:43:45, Marius Bakke wrote:
> 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.
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/
- `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, 2017/02/10
- Re: `guix pull` over HTTPS,
ng0 <=
- 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
- Re: `guix pull` over HTTPS, Marius Bakke, 2017/02/28