[ocaml-platform] OPAM: signing the repository

[David Sheets]

On 06/05/2015 01:31 PM, Hannes Mehnert wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA384
>
> David,
>
> 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.

Thanks,

David

> Hannes
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCQAGBQJVcZatAAoJELyJZYjffCjuvGwQAKayQl+94d7oj2X5NOiMyDmz
> MhNbMZOxfHlWDB2HqtE+rBqv3c96bKB2j8/Pd22BEGbDin6JE1THno2ozBF1cKI1
> u/nOVY4A7Br2wwmd6qaDh3nP/VNglXCyP5mUnPhTaVZpGgSBHDAa/imGE59f6f/z
> PAUKseNmc0dume2Tz9GeTfYDeVNfEA2wqS+FoUbV/wpGKdVfVRTUwB6AHkWJqGsi
> 7cb1ry4ceSh+FWemxd60icIGW9oU8cBjEdJka11sYYwOAEd4F9XO+8JNZVvY6qfo
> ZjJDK0YssQatxua7Lob0TSAL2cfcJGjlxvKr0T9ET26m+8EvuO8qYaMBzECTnB6r
> EXC6jWPQC72OY3W2aXLmUndYflLH6IBTppsKwsoU+oOtwPZj7C90FpW8+shShMm/
> 3Ca22Qz+wEQ9/vUwT4yFqrc3tGNqZgpDPVv3Yyt8t8Pn7379THT4gsD5hSHAVZhf
> R7ARlp/Gks68rK9Ix/HfE44yKMZ4I8zyz8KygjzruDdUiugBji6mCLbZ9vxS0HEU
> E6b6u8GxrnOWenPyc9mAJ27Ez8SzELbnGpfffQb3eJESztU4dRNO9/CdqwuOcXyJ
> yaNkLdwuld3PJjoYJ+kHHst27QfvZ3UL4Luh3tfbDHLvlHSk2ccgFS0B34TbGt0K
> IeaePU2UXrd2jkBHCaXX
> =ZvVJ
> -----END PGP SIGNATURE-----
>