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

transports/tls: Add libp2p-tls as per spec #2945

Merged
merged 57 commits into from
Oct 24, 2022
Merged

transports/tls: Add libp2p-tls as per spec #2945

merged 57 commits into from
Oct 24, 2022

Conversation

thomaseizinger
Copy link
Contributor

@thomaseizinger thomaseizinger commented Sep 26, 2022

Description

This code is mostly extracted from #2289. I've tagged everyone who made contributions to that PR as co-authors (cc @kpp @dvc94ch @elenaf9 @mxinden) in the first commit.

On top of that, this also adds an implementation of the Upgrade{Inbound,Outbound} traits so that TLS can be used with other transports. Finally, this PR also makes an effort towards libp2p/specs#459 by including a few static tests (cc @marten-seemann).

Links to any relevant issues

Open Questions

Open tasks

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • A changelog entry has been made in the appropriate crates

@thomaseizinger
Copy link
Contributor Author

Unfortunately, it seems ring is not WASI friendly https://github.com/libp2p/rust-libp2p/actions/runs/3125423794/jobs/5069777479#step:9:36.

@kpp
Copy link
Contributor

kpp commented Oct 6, 2022

The mapping looks sound to me but we may be handling too many cases.

I had to dig into RFC for TLS 1.3 to get the list of algorithms. These are not "too many", these are actual list of supported algos.

@thomaseizinger
Copy link
Contributor Author

The mapping looks sound to me but we may be handling too many cases.

I had to dig into RFC for TLS 1.3 to get the list of algorithms. These are not "too many", these are actual list of supported algos.

Yep, I've been down that road too when working on the code :)
What are your thoughts in regards to the snippet from rustls that I linked above? That only handles a much smaller set of algos.

@kpp
Copy link
Contributor

kpp commented Oct 6, 2022

What are your thoughts in regards to the snippet from rustls that I linked above?

I could use https://github.com/barebones-x509/barebones-x509/ and reuse their code to minify the code in the tls module. But when I tried to dial to a go implementation it didn't work. (the crate was/is OK, we didn't use it properly).

So I carefully rewrote it controlling every part I could and trying not to bloat the code but to keep it reasonable. It took me a month or so to figure out what's broken. So the code can be compatible with the go impl and does not break on a weird but acceptable by RFC configuration.

You are free to refactor as you like leaving the authorship and copyrights. Feel free to ping me for an extra code review. I will be happy to assist.

I could take all existing commits and put another one on top that deletes all the QUIC code. Given that we squash-merge, I am not sure it makes a big difference?

I don't know what's the point of co-authorship with squash-merge. The code was originally written by @Demi-Marie in #1334 and rewritten by me looking at their code and at the barebones-x509 crate. So their co-authorship is not an open question.

@thomaseizinger
Copy link
Contributor Author

thomaseizinger commented Oct 7, 2022

What are your thoughts in regards to the snippet from rustls that I linked above?

I could use barebones-x509/barebones-x509 and reuse their code to minify the code in the tls module. But when I tried to dial to a go implementation it didn't work. (the crate was/is OK, we didn't use it properly).

So I carefully rewrote it controlling every part I could and trying not to bloat the code but to keep it reasonable. It took me a month or so to figure out what's broken. So the code can be compatible with the go impl and does not break on a weird but acceptable by RFC configuration.

You are free to refactor as you like leaving the authorship and copyrights. Feel free to ping me for an extra code review. I will be happy to assist.

I am not planning to as I don't think I have the necessary knowledge at this point. Thanks for your prior work!

I could take all existing commits and put another one on top that deletes all the QUIC code. Given that we squash-merge, I am not sure it makes a big difference?

I don't know what's the point of co-authorship with squash-merge. The code was originally written by @Demi-Marie in #1334 and rewritten by me looking at their code and at the barebones-x509 crate. So their co-authorship is not an open question.

I am planning to attribute co-authorship to all people involved in this code on the squash-merge commit. I think that is fair. Please let me know if you disagree!

In particular, am planning on including the following (in alphabetical order):

Co-authored-by: David Craven <[email protected]>
Co-authored-by: Demi Marie Obenour <[email protected]>
Co-authored-by: Elena Frank <[email protected]>
Co-authored-by: Max Inden <[email protected]
Co-authored-by: Pierre Krieger <[email protected]>
Co-authored-by: Roman Proskuryakov <[email protected]>

@thomaseizinger thomaseizinger requested review from mxinden and kpp and removed request for kpp October 11, 2022 12:11
@thomaseizinger
Copy link
Contributor Author

This is ready to merge from my end. @mxinden @elenaf9 Waiting for your input / approval :)

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.

This is good to merge from my end. Please go ahead @thomaseizinger unless @elenaf9 has any objections.

I am in favor of adding the above list of co-authors to the squash commit.

@@ -0,0 +1,29 @@
[package]
name = "libp2p-tls"
version = "0.1.0"
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
version = "0.1.0"
version = "0.1.0-alpha"

To the best of my knowledge, the code below has not run in any production systems.

To communicate expectations, I suggest releasing this as an alpha first.

See also same suggestion on QUIC pull request #2289 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

On it!

Most users depend on libp2p though so they are not going to see this version. IMO we are effectively removing that "alpha" label again through the re-export.

Do you think we should perhaps not re-export the TLS implementation yet so users have to depend on it manually?

Copy link
Member

Choose a reason for hiding this comment

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

Most users depend on libp2p though so they are not going to see this version. IMO we are effectively removing that "alpha" label again through the re-export.

That is true. Though I would explicitly call it out in the changelog.

Do you think we should perhaps not re-export the TLS implementation yet so users have to depend on it manually?

I don't have an opinion here. I think we should be consistent with libp2p-quic. Chatted with @elenaf9 quickly. She prefers not removing libp2p-quic from libp2p.

Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think about annotating the re-export with the unstable attribute macro @thomaseizinger ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What do you think about annotating the re-export with the unstable attribute macro @thomaseizinger ?

That is specific to the Rust compiler from what I know, I don't think you can use that actually?

Copy link
Contributor

@elenaf9 elenaf9 Oct 22, 2022

Choose a reason for hiding this comment

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

Ah yes you are right! Don't have a strong on opinion on whether to re-export tls and quic or not. I did not consider that when re-exporting we "hide" the alpha-flag, so maybe not re-exporting is the best solution after all.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think not exporting it would be the better solution but I don't want to block this PR on it. We can always change that until the next release.

@thomaseizinger
Copy link
Contributor Author

Currently blocked on libp2p/test-plans#60.

@thomaseizinger thomaseizinger merged commit 159a10b into master Oct 24, 2022
@thomaseizinger thomaseizinger deleted the libp2p-tls branch October 24, 2022 00:54
mxinden added a commit to mxinden/rust-libp2p that referenced this pull request Oct 25, 2022
Given that libp2p#2945 merged, we can remove
the TLS section here.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add TLS Handshake
6 participants