[ocaml-platform] OPAM: signing the repository

[Hannes Mehnert]

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


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


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