-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 On 06/05/2015 13:46, David Sheets wrote: > 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?
Yep. >> 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? The initial bootstrap key will be a special entry in the root file. Making it valid only before a specific commit sounds like a good idea. > 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? It shouldn't. Intended is to use the user@host as identifier (thus, uniqueness). Not sure whether there is a need for a hash over the public key (keyid). > Is there a reason that keys/root doesn't reference the > keyid/authorid in keys/dev? What happens if they are not > equivalent? For RMs, the key will just be in keys/root rather than keys/dev. But we could also put only the user@host ids into keys/root, and have the RM keys in keys/dev without trouble I believe. >> 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. First things first.. Thus, first an implementation of the opam signing. If you have ideas/thoughts about identities, let us know :) Hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCQAGBQJVcZzTAAoJELyJZYjffCjugsQP/2LA+4GagnipkbQynlZrm3EN JgFJCYDUugOsvWlHUu8zlJBQEhFTix1szW8Jm2hNFU31gj0m6dDMPlpWOKSlBQsX zb7sMp5tEaMdCbOk1it0heEzA4InfMVsP5sJJ/GNDW//Sgm8fKiQfci/od13aL0e k8q9fWUT9bQD4Vyurppm0fcriGqTxR7NOFk2TdKh2idQ8n0tcMg9VFh29axyxIYZ 79QolOxduL342AfXXOEbj5zwAtIz4y7HefmlUzPYUCNM+BKEAU3+A2ElF/vNYh5w ZaV21QVuQQ301i+vW+VrTD+stWZP+gPDH20XKz+/E1fr0BrDgGCQV6OOj55NgxXE tRDnJBqNNloSDR+DhABbDl8vHYeJr3MX5g95h5KPT70SL5loewRYnNREw8XRS0DM OYNnuxvYsYY9YzupEw9+j9L5t+uzjN96Ar+57CEWG/swttvki2aF5ILQ0lYgJGvq IaChCyS0Rcyi0HabICXmgwCR/YTqARIQS+oDlbFOZU7j0L8TJheOxYjFWzrEsilH Z64k+yC+wh99cf/VVB/6iEjW6iAA9sTd634DddRCTSiQt7DH+DA/hnnSBks/aZik u7xoFdXcO0dQTtMIz4YIjrNFuxEj8YwvzPNGNdmVg5PbAbp6yseI9+tmXxd1CkKB ppIun2X+B1W7OwnFkTVC =hGXX -----END PGP SIGNATURE----- _______________________________________________ Platform mailing list [email protected] http://lists.ocaml.org/listinfo/platform
