-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
embed public keys inside ipns records, use for validation #5079
Conversation
License: MIT Signed-off-by: Jeromy <[email protected]>
namesys/validator.go
Outdated
if entry.PubKey != nil { | ||
pk, err := ic.UnmarshalPublicKey(entry.PubKey) | ||
if err != nil { | ||
// TODO: i think this counts as a 'malformed record' and should be discarded |
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.
@Stebalien WDYT? I think enforcing that the data in that field is valid and that it matches the expected peerID is the right thing to do.
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.
Yes, makes sense.
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.
I agree. If the user specifies the public key, it had better damn well be correct.
namesys/validator.go
Outdated
log.Debugf("public key in ipns record failed to parse: ", err) | ||
return nil, err | ||
} | ||
expPid, err := peer.IDFromPublicKey(pk) |
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.
This could fail if the user manually created the peerID differently than this function does (for example, made their key the hash of a public key that this function would choose to embed). I'm not sure how much of a problem is
License: MIT Signed-off-by: Jeromy <[email protected]>
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.
I don't know much about IPNS (nothing really) but the logic sounds good to me, +1 on adding the comments/explanations which made the PR much easier to understand and review. Newbie question: this won't be necessary with elliptic keys because of the MaxInlineKeyLength
restriction? Smaller keys will always be inlined (identity hash)?
Correct, smaller keys will be inlined, and we won't need to embed them in the records anymore. |
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.
code LGTM, but I'd add a test for non-matching peerid-pubkey case.
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.
SGWM
License: MIT Signed-off-by: Jeromy <[email protected]>
License: MIT Signed-off-by: Jeromy <[email protected]>
Currently, publishing ipns records to 0.4.{14,15} nodes using a key other than your peers key is unlikely to succeed, as those peers will throw away the record upon receipt if they don't have the corresponding public key. In tests, this isnt noticed so much as the set of peers we push the public key to overlaps heavily with the set of peers we push the ipns record to. In the larger network, that is not the case.
In any case, publishing the public key separately is just a bit weird. We really should have been doing this the whole time. It's not that many extra bytes, and it saves us a whole separate lookup in many cases. Plus, when embeddable ed25519 keys become widely used (support for which was just merged) we won't even need this code :)
Looking for some review while I work on some tests for this.
License: MIT
Signed-off-by: Jeromy [email protected]