Re: `guix pull` over HTTPS

[Leo Famulari <leo@famulari.name>]

[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]

On Sat, Feb 11, 2017 at 03:28:52PM +0100, Ludovic Courtès wrote:
> Marius Bakke <mbakke@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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]