[opam-devel] Package signing (was Re: OPAM 1.3 roadmap)

[Louis Gesbert]

> - Daniel Bünzli, 11/03/2015 04:49 -
> Le mercredi, 11 mars 2015 à 03:39, Louis Gesbert a écrit :
> > * the upstream package archive (and possibly its url and mirrors ?)
> 
> If we trust the hash function (i.e. not md5) signing the hash of the archive seems sufficient no ? We don't really care where it comes from, we care about the content.  

An attacker could then divert the download attempts to any url; mostly harmless, I can't imagine leveraging this for a DDos. But it can still prevent you from updating, without knowing the reason.
Another attack mentionned by TUF is feeding an infinite datastream to the download (blocking the update, possibly filling the disk and causing trouble) ; so we should be sure to include the file size somewhere.


> > No better solution than letting the modified package get signed by a general repository maintainer, maybe with a time window for the rightful owner to sign it ? I'll think some more about it.
> 
> This seems ok to me and rather an UI issue. E.g. as a repo end-user I'd like to be informed of the fact ("the meta data has been modified by the repo maintainer X") on installs/upgrades. As a package maintainer I'd like to be notified of the change and be able to agree to the change by signing the change after having authenticated it (through a single command line invocation !) at which point the end-user warning should disappear for him on further repo updates.

That sounds like a fair workflow. There could be automatic maintainer notifications for such cases (by mail, and why not on github, but we shall not depend on it)

> > But having opam-publish generate, and manage keys would be a definite gain in usability IMO.
> 
> Or opam itself.  

Worth considering, but OPAM doesn't do anything related to packaging and publishing at the moment (unless you count package pinning): it could be in the same program but in clearly separated modules.

   
> > * We should require maintainers to sign their packages -> the clients shouldn't accept unsigned packages by default, but there could be "unclaimed" (repository maintainer handled) signatures on the repo to begin with.
> 
> What about pins ? This is where git signed commit could be interesting.

Pinning allows you to specify any source of your choice for a package, and to modify it. Adding signatures there sounds cumbersome -- we may put a warning on pinning to a remote source ("you're leaving OPAM-secured territory") but relying on the underlying security (e.g. git+ssh) sounds OK to me at the moment. I don't grasp where exactly signed commits would articulate.

> > * Last, I'd like your advice and opinion on the algorithms and signing to use. Small elliptic-curve based signature (ed25519) seem to be all the hype now with stuff like signify or minilock. What is the state of what we currently have in native OCaml, and what would you recommend ?
> 
> One note about that, I'm personally not very cryptographically advanced and don't use the gpg stuff but with the years one thing I got to know a bit the ssh key-based authentication infrastructure. I don't know if that's a good idea or not but maybe we could try to hook in that infrastructure as I suspect a lot of devs are familiar with it and it would avoid creating one more of these "be careful" directories. Besides it could provide OS level ssh-agent integration which is quite handy from an UI point view (which is one of my fear in all this, there's already so much publication bureaucracy).  

Not sure if using the same key for signing and e.g. pushing to github over ssh can be an issue or not. On the publication bureaucracy, that's very high in my concerns indeed -- ssh-agent sounds handy indeed, but I'll let Hannes give advice on that. I haven't heard of using the ssh rsa private key for signing, so there might be a reason for that...

Cheers,
Louis