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

[Anil Madhavapeddy]

On 11 Mar 2015, at 02:39, Louis Gesbert <louis.gesbert at ocamlpro.com> wrote:
> 
> * Allowing non-maintainer updates: I have been wondering about this as well. It's not easy, and modification of dependency constraints can be an attack vector already (adding a dep to a compromised package, or even an unsafe older package version). Sometimes, there is also a trivial packaging bug, and the repository maintainers should be able to fix it if the package maintainer is not responsive enough. We could try and detect 'innocuous' changes, but that sounds like something that can get too complex very quickly and will open more weaknesses. 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.

I do think it's important that we retain the ability to do packaging updates without the maintainer signing it.   Most obviously, this would let the tools do mechanised rewrites, as we did for several migrations in the past.

Any such updates would have to be signed with the correct maintainer key, of course.

> 
> * opam-publish: I'd like to see it get more widely used. Maybe I should make it more clear that the first step (`opam publish prepare`) only gathers metadata locally and is very generic, while the second (`opam publish submit`) is github specific and bound to opam-repository by default. Anyway, the signing process will be open and should be reproducible by hand, with minimum hassle. But having opam-publish generate, and manage keys would be a definite gain in usability IMO.
> 

Agreed.  The only reason I'm not using opam-publish right now is that it conflicts with ctypes (due to Dose).  That's fixed in the upcoming Ctypes 0.4...


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

Right -- that would be all of them to start with, and the moral equivalent of "contact at ocamlpro.com" :-)

> 
> * dependencies to command-line utilities: OPAM's parallel command engine relies on parallelism at the sub-process level (we don't want to embed lwt into OPAM); but having our own download handling would certainly help with several issues, also including portability.

I have a nice little way to do mirroring of distfiles btw.  An `opam-fetch-url` that checks to see if it has a copy of the distfile URL+checksum in opam-repository/distfiles and just returns that if so, rather than going to the Internet.  It just works with OPAMFETCH in OPAM 1.2.1 without requiring any further modifications.  Yay!

-anil