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

Wed Mar 11 11:53:34 GMT 2015

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":
<name>,<size>,[<hash-algorithm>,<hash-value>]+

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

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

agreed.

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

true.

> 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
https://moderncrypto.org/mail-archive/messaging/2015/001559.html)

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

hannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCQAGBQJVACy+AAoJELyJZYjffCju8ggP+wYwMU7bPLVNYBlS4PyXSPrM
HLEFToldVAREWLciKfrGn2/tcpLiiBFLU5luyKt0i4l5Wtx4icZbS4o+BzKyFJMW
e1TKOmmjrI8DphNRraI/4URIgFHCjRib9PRTtQYaQ3hW89/SnShgkALE9lO+3Fr6
3GOIqIBR5g0LayJ8slUm3c2Fj+cx3OuDYBtMYiNqSkAW1UPheSckOuHcop/DvSAz
x7xnuVqhybi+/+UZQKQnFBACOv6DmNdCj6AB+IE/L0p4EABxc/HodLHX05UPR2ru
Uk/fxHtUph3JkxcuoJuRvjgaQpOVDh7/nFDIWwRnwW0ZZdEkjNE3MluRQy0ZfCNK
Mz0RK2PD7E5LqIVDiZj4tW9bt2EIH9lYeleU9ZPgQDJzuQ3pAscIiAIZxYHORVLV
gihXpUfNKYK7Ps7aYHYlmGQgsqsLK1yJo/LGsLJLYiByB63H1AJIuYh7/20juep0
lqkWcntfuExtvxUOefZheVrdsX5wC06bf4zx6GicMka9r9dqE9Td1p+eqCEVMY4k
C/6XePWfDY5Cjp6Q5X3+XpXKphX6lLo+BsPaaMZPKO6SOF8hrvMYk/Hf7CVJbNHj
mMim/qOIT40D2LVyszbuMgG4lsNt3BSVMKPgp5v4cR3ELYkJ63dyBPNX4sNup8T0
GYVB6WCq7o0cGjDrA870
=xtFb
-----END PGP SIGNATURE-----