[ocaml-platform] OPAM: signing the repository

Hannes Mehnert hannes at mehnert.org
Fri Jun 5 13:31:41 BST 2015

Hash: SHA384


On 06/05/2015 11:47, David Sheets wrote:
>> Wow! This is really nice work.

Thanks! And thanks for your questions!

>> 1. In your linearity invariants, you say that no key may be
>> removed (1) which seems sensible even if inviting a lot of cruft
>> eventually. Then, you say that keys can only be modified with a
>> signature (5) and, as a special exception, removal of a developer
>> key (exception 2) is allowed. What happens when these events
>> occur? Do things get re-signed? Do clients have to traverse the
>> repo history to extract old keys to verify signatures?

The first ones are the linearity invariants for each commit. Addition
is pretty straightforward.

A modification is still ok, since there can be signatures on the
modified data. Deletion is the hard bit: there is nothing afterwards -
thus the commit must contain an annotated tag storing signatures that
the deletion was intentioned.

Whenever a key is removed (on a compromise/steal event), all the
signatures done with this key are considered to be invalid. No need to
traverse history.

>> 2. Are the default opam root keys compiled into the binary or
>> on-disk? I interpreted it both ways from a couple of mentions
>> throughout the doc.

Shipped within the binary (for the main opam repository), and used to
verify the signed root file in the repository.

>> 3. How will the uniqueness and time-limitedness of the
>> initial-bootstrap key be enforced?

It will be generated once, all the things will be signed, and then
purged from its existence.

>> 4. Where are RM keys stored in the repo? in keys/dev? keys/root
>> seems to contain a list of the keyid/algo/key triples for RMs but
>> there is a keyid uniqueness condition...? Could you clarify the
>> distinction between a keyid and an author id (user at host)?

RM keys are stored in the root file. A keyid and authorid are the
same, authorids must be unique (across package and repository
maintainers, although stored at different places). Since the amount of
RMs is bounded, and their keys will be needed during most runs of opam
anyways, they will reside in memory. Thus, a lookup for a specific
keyid/authorid will first lookup in the set of RMs, then in the
package maintainer directory (keys/).

>> 5. Can the dev (and RM) identities be designed for extensibility?
>> It reads like the key files will just contain a list of key
>> triples right now. Could these files contain a single field, e.g.
>> "keys", so that others could be added later? Specifically, I
>> would like to attest to my GitHub user id so the signatures in
>> the repo can be used by bots to authorize simple actions
>> performed by my GitHub user (e.g. rebuild this PR).

Yes, we removed the not-yet-finished part about what is contained in
keys/authorid (and how certain parts of it are verified). We want to
couple them to GitHub user ids, and email addresses -- and have some
form of automatic validation (similar to keybase.io).

Version: GnuPG v2


More information about the Platform mailing list