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

Hannes Mehnert hannes at mehnert.org
Wed Mar 11 11:53:34 GMT 2015

Hash: SHA384

On 03/11/2015 02:39, Louis Gesbert wrote:
> # On the current state
> the current client-server protocol and repackaging of archives are
> kind of there by legacy more than by design, and this could be a
> good opportunity to improve on them

great to hear.

> # Proposal (just random remarks)
> Threat model: * an attacker can compromise the repository

what does this mean? as mentioned, I'd prefer to have the repository
being untrusted.

> Package signature: this should probably sign over * the package
> definition, excluding the url file (everything under
> `~repo/packages/<pkg>/<pkg>.<version>/`) * the upstream package
> archive (and possibly its url and mirrors ?)

I'd hash all the files of the package definition, and the tarball, and
keep a list in the file "checksums":

thus, replacement (or multiple) hash algorithms can be used. the
<checksum> in url is no longer needed.

let's start with SHA-256. signature is made on the SHA-256 hash of

> Key delegation: * We can simply delegate to sub-directories of the
> repository * OPAM should probably be changed not to accept package
> definitions anywhere in the hierarchy then (I _think_
> `~repo/foo/foo.1/bar.1/` would work as a definition for `bar.1` at
> the moment, OPAM makes no assumptions on the hierarchy)

both good points.

> Root key: * TUF propoposes several root keys with a threshold. That
> could be a nice security since it makes revocation of root keys
> possible.


> claimed/unclaimed/recently claimed maintainer keys (from Python's
> pep480): * I think we'll need some kind of 'unclaimed' at least to
> ensure the progressive migration to signed packages, having all
> maintainers sign up-front before rolling 1.3 sounds difficult. Then
> we don't have Pypi's flow of incoming packages, so we may not need
> as much infrastructure -- having a default delegated maintainer
> could be enough.


> Timestamp server: * I'd love to see that done by a unikernel that
> fetches from github, signs, then pushes back to the repository HTTP
> server. Still needs to get its key from somewhere though.

in fact, that was my idea as well.

> # open questions
> * 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.

sounds good.

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

it should prepare "checksums"

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

and running opam within a unikernel :)

> # some more * Would we want to use the TUF specified json format ?

or sexp, since that's already a first-class citizen!

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

this whole minilock seems to be a not-yet-though-out-idea (looking
into the thread

what we have
- - cryptokit (RSA/DH/hashes)
- - cryptohash (hashes)
- - ocaml-sha (sha)
- - ocaml-nocrypto (RSA/DH/DSA/hashes)
- - ocaml-sodium (bindings to libsodium/nacl [curve 25519])

what I'd recommend: be agile! use a keytype and keydata field --
initially support both RSA and ED25519 keys (I believe PyPi people did
the same).

Version: GnuPG v2


More information about the opam-devel mailing list