Skip to content
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

Don't take ownership of key in SignedEnvelope::new (#2510) #2516

Merged
merged 1 commit into from
Feb 15, 2022

Conversation

laurentsenta
Copy link
Contributor

@laurentsenta laurentsenta commented Feb 14, 2022

Fixes issues #2510

  • don't take ownership of key in SignedEnvelope::new
  • clarify if we want / should use a ref through all the code instead of making a clone
  • don't take ownership of key in PeerContrustor::new

@mxinden
Copy link
Member

mxinden commented Feb 14, 2022

clarify if we want / should use a ref through all the code instead of making a clone

I am not quite sure I follow. Could you expand on this @laurentsenta?

@mxinden
Copy link
Member

mxinden commented Feb 14, 2022

To reproduce CI testfailures locally you can run cd core/ && cargo test.

@laurentsenta
Copy link
Contributor Author

laurentsenta commented Feb 14, 2022

@mxinden
regarding:

clarify if we want / should use a ref through all the code instead of making a clone

According to this doc, the keypair is the one used to authenticate every connection. But it looks like we clone this key when we want to use it.

Would that make sense to make the relationship explicit by using a reference in the PeerRecord too, instead of a clone?
So similar to borrowing the key in SignedEnvelop, should we also borrow the key when we instantiate a PeerRecord?

@mxinden
Copy link
Member

mxinden commented Feb 14, 2022

clarify if we want / should use a ref through all the code instead of making a clone

According to this doc, the keypair is the one used to authenticate every connection. But it looks like we clone this key when we want to use it.

Would that make sense to make the relationship explicit by using a reference in the PeerRecord too, instead of a clone? So similar to borrowing the key in SignedEnvelop, should we also borrow the key when we instantiate a PeerRecord?

Good callout @laurentsenta. Off the top of my head there is no reason why PeerRecord and SignedRecord should not take a reference only. Maybe @thomaseizinger has thoughts here?

@thomaseizinger
Copy link
Contributor

clarify if we want / should use a ref through all the code instead of making a clone

According to this doc, the keypair is the one used to authenticate every connection. But it looks like we clone this key when we want to use it.

Would that make sense to make the relationship explicit by using a reference in the PeerRecord too, instead of a clone? So similar to borrowing the key in SignedEnvelop, should we also borrow the key when we instantiate a PeerRecord?

Good callout @laurentsenta. Off the top of my head there is no reason why PeerRecord and SignedRecord should not take a reference only. Maybe @thomaseizinger has thoughts here?

Yes, skimming the code it makes sense :)

@laurentsenta
Copy link
Contributor Author

Thanks for the feedbacks! I pushed another commit with the tweak,
The PR is code complete, cargo check & tests are passing on my machine

@laurentsenta
Copy link
Contributor Author

Thanks for the review, @thomaseizinger! could you merge, or should I ping Max? I don't have write access on the repo yet.

Copy link
Member

@mxinden mxinden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing a changelog entry in core/CHANGELOG.md. Otherwise looks good to me.

@laurentsenta
Copy link
Contributor Author

@mxinden Fixed, thanks for the check!

Copy link
Member

@mxinden mxinden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the help @laurentsenta.

@mxinden mxinden merged commit df4905d into libp2p:master Feb 15, 2022
@mxinden
Copy link
Member

mxinden commented Feb 15, 2022

First patch merged @laurentsenta 🎉

@laurentsenta laurentsenta deleted the fix/2510-key-ownership branch February 16, 2022 07:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

core/src/signed_envelope: Don't take ownership of key in SignedEnvelope::new
3 participants