[ocaml-platform] OPAM: signing the repository
dwws2 at cam.ac.uk
Fri Jun 5 13:46:29 BST 2015
On 06/05/2015 01:31 PM, Hannes Mehnert wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.
Ok. If I understand you correctly, modification of a key will require
resigning all non-malicious objects that used to be signed by the old
version of the key?
>>> 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.
So the public initial-bootstrap key will be baked into opam like the
root key? Will there be any safeguard against later re-use of the
"purged" key? Maybe the snapshot bot could check that the
initial-bootstrap key is only ever used before a specific commit?
>>> 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/).
So the file keys/dev/user at host will contain triples like:
[ [ "user at host" "algo" "key" ]
[ "user at host" "algo2" "key" ]
? Can the pair of keyid/algo recur? Is there a reason that keys/root
doesn't reference the keyid/authorid in keys/dev? What happens if they
are not equivalent?
>>> 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).
Cool! I look forward to that design.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> -----END PGP SIGNATURE-----
More information about the Platform