Updates to README #279
Updates to README #279
Conversation
These updates to the README are based on my reading the TUF spec and talking to knowledgable people. I had a hard time understanding the original README, and I hope that this helps others who follow after me.
|
Thanks @david-christiansen ...am I assuming correctly your next PR will fix #249 ? 😅 |
|
In that case, let me merge so that David is free to work on #249. David, thank you very much! |
|
Doh. |
| ### Root Keys | ||
|
|
||
| The Hackage root keys are held by trusted members of the Haskell community. A | ||
| signature is valid when three keyholders have signed. This means that the |
There was a problem hiding this comment.
Is it worth remarking that the number three is configurable (specifically via the threshold field)? Perhaps not here, but somewhere the page could explain the semantics of thresholds.
There was a problem hiding this comment.
That seems like a valuable change. I'll make it.
There was a problem hiding this comment.
See #280
| 4. Delete the existing signatures. | ||
|
|
||
| Each holder of root keys should do the following: | ||
| 1. Install `hackage-root-tool` on the signing machine and ensure that the key is present. |
There was a problem hiding this comment.
- Verify to their satisfaction that the new
root.jsonis correct. (Perhaps we should specify more precisely what the root keyholders are checking?)
There was a problem hiding this comment.
Good point. I'll submit a new PR with a revision.
There was a problem hiding this comment.
See #280
|
|
||
| ### Operational Keys | ||
|
|
||
| The operational keys do not presently require regeneration, unless the private keys have been lost or compromised. |
There was a problem hiding this comment.
Would it make any sense to rotate the operational keys occasionally anyway, in case of undetected compromise?
There was a problem hiding this comment.
I think that it would, but I want this text to document what is done. I think that this policy should be changed in the way you suggest, and that the README should be updated at that time.
There was a problem hiding this comment.
Shall we open a ticket with that proposal? In which repo?
There was a problem hiding this comment.
That's fair. Do we have an issue tracker for recording such unresolved policy questions? I'm not certain whether to use this repo or https://github.com/haskell-infra/hackage-root-keys/issues for example.
There was a problem hiding this comment.
Honestly, I think the whole thing needs a bit of an overhaul, and I'd like to collect discussion on that somewhere. Some things I think we need to discuss:
- Rotation of root keyholders to ensure robustness in the face of people being busy or otherwise unavailable (perhaps, we expect all keyholders to sign all rounds, even above the threshold - if you don't sign two rounds in a row, then you get replaced)
- Key rotation for operational keys, and coordination of operational key renewal with root re-signing
- Explicit responsibility for getting re-signings going in time, and reminding everyone (my suggestion is that HF sends the reminder emails)
- Techniques for ensuring bootstrappability by older clients in the face of root key changes (e.g. if I wake an old VM image up, how do we ensure it can
stack buildorcabal updateif there's been root keyholder changes?)
|
Unfortunately, I don't have time to do #249. These are docs that I am producing as a side effect of running the process, and it seems useful to put them where others will see them rather than saving them for myself. :-) |
When I was first trying to understand this framework, I had a hard time understanding the contents of the README, which seemed to assume more background knowledge than I had.
I've attempted to write up that background knowledge for inclusion here, so that other new readers have an easier time.