opam: support signing repository

[edwintorok]

Currently the opam repository is updated over http, and there are no signatures on the packages/repository. An improvement would be to update over https, but that wouldn't protect against a compromise of the repository server/user account, or a mitm attack on the ssl cert.

There are already checksums for archives (in packages//url), and checksums for all the files in the repository (in urls.txt), so you are halfway there.

It'd be nice if there was also a .sig file that signs the urls.txt, and if you used a stronger hash (in addition to) MD5 (at least SHA1, but SHA2 is supported pretty much everywhere nowadays).
opam would carry the public key, and opam-mk-repo would have to be pointed to the private key to perform the signing.

For private repositories (the ones with opam remote add) you could have the option to disable signing, or to add another public key to opam.

As for implementing this in opam you could either invoke gpgv, or do it yourself using cryptokit (but that'd add a dependency on cryptokit for opam).

Once this is implemented that leaves unauthenticated only git URLs in packages. Maybe a flag --secure to opam could forbid installing of packages from git URLs, or packages that don't have checksums.

I think this simple signing of urls.txt would suffice, as it is assumed that whoever signs urls.txt with the private key has also checked that all the packages and their source codes come from trusted sources, and that the checksums are correct.
A more complicated signing scheme where each package is signed by its respective maintainer is not needed, as git already provides a way to authenticate pull requests, see:
https://www.kernel.org/pub/software/scm/git/docs/howto/using-signed-tag-in-pull-request.html

[samoht]

The initial design goal of checksums and such was to have a reliable (but not necessary perfect) way of detecting upstream change, in order to rebuild packages which have changed.

However, I agree that having signed packages would be nice, but this will not be done before the 1.0 (at least not by me ... but if you want to contribute patches, you are always most than welcome :-) ). I'm moving the issue to "ongoing" to keep track of the idea.

[samoht]

Also, maybe this can be done by an external program (ie. opam-safe-repo) ?

[edwintorok]

On 2013-02-03 19:42, Thomas Gazagnaire wrote:

Also, maybe this can be done by an external program (ie. opam-safe-repo) ?

There could be 2 opam packages for the client:

• opam-keyring for key rollover, i.e. updating the signing keys
  opam-keyring would work similarly to debian-archive-keyring, and opam distribution would come with latest key for bootstrapping)
• opam-secure-repo for checking the signatures, i.e. it'd contain the opam-safe-repo tool
  • at first this tool could just invoke the external 'gpgv', but one could implement it with cryptokit too

When opam is first installed and 'opam init' is run it should automatically install these 2 packages,
unless the user chooses not to.

Then key rollover is simple: just publish a new opam-keyring package, signed with both keys, and some time later
signed just with the new key. This is similar to how debian-archive-keyring and apt-secure(8) works.

For the server/repository side I was thinking that ocaml-mk-repo could invoke gpg directly,
because most people would have their private keys managed by gpg already.

--Edwin

[hannesm]

this would obviously depend on some OpenPGP implementation or binding in OCaml - is there one which I haven't found yet?

[edwintorok]

Perhaps signify would be something simpler to implement.

[avsm]

+1 to signify.

On 22 Jul 2014, at 11:17, Török Edwin notifications@github.com wrote:

Perhaps signify would be something simpler to implement.

—
Reply to this email directly or view it on GitHub.

[cfcs]

A friend recently referred me to this project which seems popular for Python, Ruby Gems and Docker:
https://github.com/theupdateframework/tuf

• A good article about TUF: http://lwn.net/Articles/629426/
• I really think that TUF would be a good choice to go with -- for one, they already have a spec and an implementation, so adding support would likely be easier than rolling our own. They also have a rollout strategy for Python that we can pretty much clone.

I found this to be a good read about OpenBSDs new tool, called signify:

• http://www.tedunangst.com/flak/post/signify

Link to mailing-list discussion about the subject:

• http://lists.ocaml.org/pipermail/platform/2015-January/000531.html
• http://lists.ocaml.org/pipermail/platform/2015-February/000540.html

Erlang discussions about code signing:

• https://groups.google.com/forum/?fromgroups#!topic/erlware-questions/1esqRJU11EE

Here is a long discussion with lots of relevant links from Cabal, the Haskell package manager (who have now implemented their own pkg signing and verification):

• Packages are downloaded insecurely haskell/cabal#936

Brief recap of interesting links from that thread:

• http://blog.ontoillogical.com/blog/2014/07/28/how-to-take-over-any-java-developer/
• https://github.com/infobyte/evilgrade
• cabal does not support https remote-repo haskell/cabal#1616
  • note the bottom comment about TLS for privacy and not just integrity
  • also note that information about downloaded pkgs can likely be inferred by fingerprinting the TLS packets and the size of the downloaded content
  • also related to this is curl --insecure still needed ? #2006
• Link to research on what we're up against: http://www.cs.arizona.edu/stork/packagemanagersecurity/

By the way: This older discussion is related: #1370

• From thread, for inspiration: https://wiki.gentoo.org/wiki/Repository_format/package/Manifest

[AltGr]

Thanks a lot for the detailed overview. This is something that needs our attention.

[hannesm]

please have a look at our proposal: http://opam.ocaml.org/blog/Signing-the-opam-repository/

[cfcs]

First some points:

---

Repository maintainers are powerful, they can modify existing opam files and sign them (as hotfix), introduce new delegations for packages, etc.).

I read this as if the proposal gives RMs the ability to modify packages for which there already exists a real maintainer key, is that desirable?

---

• Do package maintainers / developer keys have an offline root key too to allow rebuilding trust if a package maintainer's development laptop is compromised? Development environments are (in my experience, at least, coming from the security world) usually not very secure, people tend to take chances, install random things, and privilege separation in a GUI environment is notoriously hard.
  There will probably be compromises of package maintainer keys, we should have a way to recover from those.

---

• What are your thoughts on dependencies? For E2E signing to be effective, dependency checking must incorporate E2E signatures as well to prevent the snapshot/RM keys from injecting fake dependencies. That means that if package A depends on B, it must include that information in its signed manifest file, including information on what package maintainer keys to expect (so that a compromised RM can't just replace the package).
  Is it within the scope of this model to protect against such attacks?
  (I'm sorry if I skipped through the document too quickly, but that part didn't appear obvious to me).

---

Apart from those concerns - good job, looking forward to it! :-)

[hannesm]

to briefly answer (prefer discussion on the mailing list mentioned in the blog article):

• 1 as it is the case already now, RM often need to adjust some upper bounds of dependencies (esp when dependent packages get new versions which are incompatible with previous ones. waiting for all devs depending on that library to update and sign their packages is not feasible.
• 2 revocation is done in the revocation (modification/deletion of keys). it is clear to us that revocation needs to be there as a first-class citizen (unlike CRLs in X.509)
• 3 dependencies are part of the opam file, which means only the developer (or quorum of RMs) can modify these

[AltGr]

On 1., also, a quorum (probably 2) of RM signatures will be required.

[AltGr]

Work is well underway on Conex, which will be our backend for this. Integration will come later on, but 2.0 should have the necessary hooks (#2647) so that this can be tested already.