-
Notifications
You must be signed in to change notification settings - Fork 319
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CIP-0052 | Add public keys to auditor table #406
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@simonjohnthompson it's good to have that extra field in the table for sure... but is this PR complete without those keys filled in? If not, should this PR be kept in abeyance until those keys are added in further commits?
We should definitely add the public keys first. I suppose we can just comment on this PR. |
sure @L-as if they're posted here in a way that allows editors to verify their validity (e.g. from the auditor's GitHub account), we can commit them if the PR author hasn't done so already. |
MLabs has a PGP-compatible key (using ed25519) suitable for signing messages. The fingerprint is 64BC640B5454215D12165EEAEEFF303D2643ABA2. |
@L-as @simonjohnthompson is the last commit clear enough according to how people will be using the table? |
I'd say so. |
Thanks @L-as for the help so far getting the key for MLabs ... @simonjohnthompson I'm marking this as Waiting for Author because this is coming up for initial review at our CIP meeting tomorrow and I (and maybe other editors) still have no idea how to get the remaining keys for FYEO, Hachi & Tweag... can you tag some GitHub IDs for them there and ask them to contribute their keys from an official source? |
Suggestion: public keys here may be added over time by a representative of each relevant party, with a commit signed by the respective private key and from an account that belongs to the party's organization. How does that sound? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. Not sure there is a reason to block this PR waiting for other entities to add something. They can just make a followup PR if they want to
It's not sound. There's a cyclic dependency. s/signed commit/PR by member of org/. |
What do you mean?
where's the cycle exactly? |
That only tells us that the owner of the key consented, not that the owner is the correct one. |
Hence the second part: "and from an account that belongs to the party's organization" |
* CIP52: added auditor public key info to auditor table (section 3). * added MLabs public key Co-authored-by: Robert Phair <rphair@cosd.com>
Added field for public key information for auditors. This to be used to verify signed audit certification metadata.