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

Hannes Mehnert hannes at mehnert.org
Tue Mar 10 18:33:55 GMT 2015

Hash: SHA384

Dear all,

let me try to propose package signing for opam (by first briefly
mentioning the current state) - and raise some outstanding questions I
currently have.  This is orthogonal to the sandboxing discussion (I
appreciate if the opam building process uses sandboxing to disallow
access to the file system and socket communication). Sorry for the
length of the mail. The system is very much TUF, but adapted for
opam's requirements.

## Current state

Please correct me if I'm wrong and/or direct me to documentation,
focussing on the 'standard' http repo:
 - the main repository (https://opam.ocaml.org) is downloaded
(core/opamSystem.ml) using either wget, curl or OpamGlobals.curl_command
[arguments passed are --no-check-certificate/--insecure]
  -> how is the sync from github done?
 - this contains of:
  a) packages (consisting of opam and checksum, plus arbitrary scripts)
  b) version
  c) config

Is only index.tar.gz downloaded? Or the full file list?

The file urls.txt contains:
 - package file names, md5, permission
 - archives/packagename+opam, md5, permission

This is generated by repositories/opamHTTP.ml. Where does the archives
information come from?

When a package is installed, the archive is downloaded either from a
mirror (this +opam url) or from the url in the package description.
Why is there repacking done and +opam URLs? Why do the md5 strings of
archives/foo/foo.x+opam.tar.gz and packages/foo/foo.x/url not match?

Thus, currently the opam repository server has to be trusted, and also
the transport layer is not authenticated (thus, a MITM might be in the

On 02/23/2015 01:07, Louis Gesbert wrote:
> # Secure the repository and updates:
> Integrate some implementation of TUF to have signed packages,
> signed metadata and signed timestamps, and allow OPAM to detect
> anything suspicious. This implies: * defining a signing and
> repository update workflow, adding as little burden as possible *
> update opam-admin to apply the signing rules * obviously, update
> opam to check all that * update opam-publish (?) to help contribute
> signed packages, depending on the chosen workflow

## (Unfortunately incomplete) proposal
What is the threat model? I personally would prefer to not have to trust
the repository server.

How to get there? Each package has to be signed by its maintainer.

Maintainer workload:
Instead of generating a md5 sum, a digital signature is generated over
all files which are relevant for the given package. This includes the
opam file (because it can execute (arbitrary?) commands during
building), patches, ... Instead of the md5, this signature is pushed
to the repository.

User experience:
Opam checks the digital signature of the package and refuses
installation on mismatch.

The transport layer between repository and user does not need to be
secured and authenticated at all! While mirrors themselves will
continue to work, repackaging of tarballs won't (unless these are
signed, and in general we try to minimize online systems which have
access to private keys).

## Key management
I use "user" for the person who wants to install a package on their
computer, and "maintainer" for the person who releases and pushes

Key management is the tricky bit!  Each repository is rooted in a
single key, which is used to sign delegation of packaging roles.  Opam
distributes the public key of its main repository with its source and
binary.  For alternative repositories, these root keys have to be
distributed and verified on a second channel (or cross signed by the
master opam repository!).  The root key is most of the time offline.

Each maintainer has a key.  opam-publish uses this to sign the package
contents.  A maintainer has to get verified out-of-band, and is then
legible to push updates for the single package.  Of course, a
maintainer can lose their key (or it might get stolen).  Therefore,
revocation must be a first-class citizen within the system (and always
delivered with repository updates).  There can also be various levels
- -- claimed/unclaimed/recently claimed (from

A user's opam uses the root key to verify the correct and legible
signature on a package.

A timestamp server signs the entire repository content every hour
(thus a) a user can detect if an attacker tries to present old
packages; and b) mix-and-match attacks are impossible)

## Trust
The time of the users system must be strictly increasing and should be
the same as the repository/timestamp server.

## Open questions
Maintainer M of package X releases a version 1.0.  It is obvious that
package Y, maintained by N, requires from now on a version constraint
< 1.0.  Should M be able to include this constraint update into the
pull request, and sign this?  Or should N intervene?  At the moment,
in opam-repository people != maintainer push such changes (which I
think is good for quick evolution and quick fixes).  Maybe a group of
'core' maintainers who can sign (only such constraint updates!?!)
should be defined (but certainly their keys are more attractive to
steal then).

Which trust model to use?  Verify key via email, web portal, or in
person by already existing maintainers (web of trust)?  Should a user
be able to blacklist and whitelist specific keys?

Is it worth to investigate GnuPG integration (signing git commits?)?
In my opinion it is not.

Can we require maintainers to use opam-publish?  Obviously there'll be
pure command-line ways to achieve the same result.

We should require maintainers to sign their packages (making it very
easy and flawless), otherwise we have a huge set of users who will
just accept everything (signed and unsigned packages) and the actual
security gains are negligable.

## Dependencies
Should opam rely on command-line utilities, as it does atm with
wget/curl?  Or should it prefer to use OCaml libraries which provide
cryptographic functionality (such as hashing and asymmetric operations)?

While I certainly prefer the latter, I'd love to hear from opam
developers what they think about it.

Let me know what you think of it!

Version: GnuPG v2


More information about the opam-devel mailing list