Log-Based Registry: phase 1 proposal#25
Conversation
|
@Kylebrown9 @lann I'm just recording a thought that occurred to me for later discussion: what if we required the hash in the |
| #### Effects | ||
| * Assigns role specified role to the specified key. | ||
|
|
||
| ### Remove Role |
There was a problem hiding this comment.
I wonder if it would make sense to collapse Assign and Remove into a single "Update Roles" type that can atomically update two keys. That might be easier on implementations than a server policy that requires batching different entries together.
There was a problem hiding this comment.
I think there are enough use cases for batched publish that even if we did combine role modifications into one, we'd probably still need it.
There was a problem hiding this comment.
Requiring batching just for an implementation to be correct doesn't seem ideal to me. The only other example I can recall discussing was "require assigning some role to the operator at log init", but that policy could simply be "the second entry must assign a role to the operator".
There was a problem hiding this comment.
I think @npmccallum had some use cases in mind where this is a useful policy tool and I've heard some interest in batching together entries responding to an incident (e.g. CVE annotations, yanks, new releases).
There was a problem hiding this comment.
If we have use-cases where multiple entries must be accepted atomically we should consider it as a feature that goes beyond "just a bunch of entries submitted together". For example, if the entries all have the same author, they really only need one signature (which would also prevent the registry from partially accepting the set of entries).
There was a problem hiding this comment.
I'm definitely interested in exploring atomicity guarantees for entry batches.
Formatting to make mdlint mostly happy
Remove mentions of using multiple hashes
Update proposal to reflect the current design
| string version = 2; | ||
| // The time when this entry was created | ||
| // Format is ISO 8601 timestamp | ||
| string time = 3; |
There was a problem hiding this comment.
If we use protobufs, shouldn't this be https://developers.google.com/protocol-buffers/docs/reference/google.protobuf#google.protobuf.Timestamp ?
There was a problem hiding this comment.
Happy to if that's the standard approach. @lann thoughts?
| string version = 2; | ||
| // The time when this entry was created | ||
| // Format is ISO 8601 timestamp | ||
| string time = 3; |
…ce#25) * Make Cranelift meetings weekly now (and add agendas). In our meeting today (2022-09-21) we discussed whether it made sense to formalize the almost-weekly cadence we had been taking (which evolved from an overflow-into-next-week scheme) into fully weekly. We agreed to do so, and so this PR adds the remaining agendas for weekly meetings for the rest of 2022 (except for Dec 28, when I believe most of us will be on holidays). * Update README as well.
| // The warg protocol version. | ||
| // Encoded using semver 2.0. | ||
| // Only legal value currently is "0.1.0". | ||
| string version = 2; |
There was a problem hiding this comment.
Semver is awkward for protocol versioning. I would stick to an unsigned int here.
4 participants
Rendered
I've worked with @npmccallum and @lann to combine their sketches into a unified phase 1 proposal for a log-based registry. The Open Questions section contains a number of remaining decisions which should be discussed and either incorporated or determined to be out of the MVP scope.
References to "hash(es)" and "public keys" are intentionally ambiguous in the initial draft, resolving how these are represented is an open question (see topics "Hashing Scheme" and "Hash Indirection") as different design choices are available. As per our previous vote, the JOSE standard will be employed; JWKs and other JOSE features will be used where keys, signatures, and hashes are needed.
Discussions for open questions