On Sat, Feb 11, 2017 at 03:28:52PM +0100, Ludovic Courtès wrote: > Marius Bakke <mba...@fastmail.com> skribis: > > 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.
My attitude about improving the security of `guix pull` can be summarized as "The perfect is enemy of the good". Unless we control the server that provides the default `guix pull` source, I don't think we should try pinning a key. I don't want to take the risk that `guix pull` breaks permamently because something gets messed up on Savannah. If `guix pull` breaks in a way that requires users to to do `guix pull --url=foo`, then we will have failed, in my opinion. I'd rather try an incremental approach, for example: 1) Fetch code over HTTPS instead of HTTP 2) Think about hosting our own infrastructure and pinning a key (but ideally we don't have to trust the Git repo infrastructure) 3) Verify Git commit signatures 4) Think about building a set of trusted PGP keys and verifying Git commit signatures against this set ... or something like that. > > 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? It's a good idea; let's try it. However, I think that pulling code over HTTPS using a certificate store like nss-certs or from the host distro is a huge improvement over what we have now. If we can do that sooner, we should. WDYT?
signature.asc
Description: PGP signature
