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

[Daniel Bünzli]

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.  
  
> 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.

> Anyway, the signing process will be open and should be reproducible by hand, with minimum hassle.  
Yes.
  
> But having opam-publish generate, and manage keys would be a definite gain in usability IMO.

Or opam itself.  
  
> * 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.
  
> * 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).  

Best,

Daniel