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

[Hannes Mehnert]

-----BEGIN PGP SIGNED MESSAGE-----
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
way).

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

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
http://legacy.python.org/dev/peps/pep-0480/).

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!

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

iQIcBAEBCQAGBQJU/zkTAAoJELyJZYjffCju8mIQAKrlHiRjsdc1cYu7lHAShRcR
3xYY6W6zuBh5ILyLQyuF146wvvTalf31xsRmKWbeQeAY+rNImzD4vCgYbD1AHhHA
GLM1bK37tXBRnDd2VROCW0RRnTHNPhqCya60JqYXzQpHwZEQnwIoz8/qgoMY8Yru
Yet8g3+axF7LMQ5RGdM1TUBz53EciZihbv6vG3HC10Msg8d1K5dXivAzBVGYRvfM
ByMw86l81RdlEzZgcz9cPsHeeWIIat5v5scVUT/ogbAewmIpPirOMYNLYxayliu5
FDV1kybW45WnpCmBGxQ5d6bbJxQx0atrSGwJjGbKTC2hvICyHq6p8jSrjxwvs1TW
0inm9tFzGFQ4AJkXEIcBJSV1qdOfjKJpUAaGr186fyix+nnlBXT642zz3DJjxnWQ
QIpWfJMMmC8IgsLbdxd41Idl75M6r1b8StuKBuKbWyjd0M7GMsch9oday02at8hf
RXwwIdvxSW0LdCaJoszpV9gb4ulA3NcXE5ZVH0YO347SLc7NlOnNfL68DHgSV23v
fkKgPFDcPeKUxqY49P66f0N7it1I4MgjTiq3aHpNL27JPAoZsOe4/zvQaU6E6T5U
j9HB8cLTXJEhKWVkHkhKpKxHQhV1ugOYGjlG9paz4QHb81lupT2/J0hOkcwSjcms
5NSI8R9zJRKQIh6q/Egf
=G57e
-----END PGP SIGNATURE-----