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@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@host will contain triples like:
[ [ "user@host" "algo" "key" ]
[ "user@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-----
_______________________________________________
Platform mailing list
[email protected]
http://lists.ocaml.org/listinfo/platform
