v2 release tracker

[daenney]

This is here to aggregate issues/PRs we'd like to see in v2:

• V2 Release! First breaking change certificate chains. #142 certificate chain validation
• Bring us closer to crypto/tls #148 crypto/tls ergonomics
• Add E2E tests with OpenSSL #11 E2E tests with OpenSSL
• Allow context.Context where it makes sense for cancellation etc.

[Sean-Der]

This is fantastic @daenney, thanks for starting! I will work on getting #142 done

Also can probably grab #11. I also want to introduce loss/jitter, might help bring out any bugs we have also.

[Sean-Der]

@daenney @jkralik @rumpelsepp I took some time off and I would like to get this done by Sunday! I just finished releasing a new version of TURN, and would like to get this done as well. Then I can concentrate more on WebRTC.

• Is there anything I can do for Bring us closer to crypto/tls #148, I don't have any changes personally.
• What do you think of updating Client/Server to take a context? I need a way to be notified that an error has occurred, and it looks like taking a Context is the proper way to have a async way to bubble up an error. I talk about it in How to be notified when *dtls.Conn is closed/Connection state #151 a bit.
• I will work on adding E2E OpenSSL tests.

[jkralik]

Hi @Sean-Der

• Bring us closer to crypto/tls #148 for this version it is good enough I think
• Context is very nice for propagation cancellation and I used it. eg: for now I must have own layer with Context over net.Conn but if Context will be integrated directly do dtls, then I can remove the layer for dtls.

[Sean-Der]

@jkralik that is really exciting that are using Context already! In your opinion what would be the best API/things that you want to make sure it can do?

I don't really work with the pion/dtls public API. I dropped it into pion/webrtc and I really haven't touched it since.

[at-wat]

I think E2E test with openssl would be awesome to have, but not a release-blocker.
Is there any remaining API/behavior breaking change to be have?

[daenney]

I don't believe so. I've just tagged v2.0.0-rc.6 so if people want to go ahead and try that out, now would be a good time.

One thing I seem to remember though, aren't we going to have to move all our code under a v2 directory for Go modules to work correctly? Since the version past 1.x becomes part of the import path. I guess we don't need to but it'll break module unaware consumers?

[daenney]

It would be nice to fix #190 before we issue a final for v2.0.0.

[at-wat]

Users disabling modules still be able to vendor the repository by any git ref and import without v2 suffix. So, I don't think it's necessary to make v2 directory.

[daenney]

Fair enough. And we do only support Go version that also support Go Modules, so I guess this is fine.

[daenney]

Alright. Officially we've done all the things we said we wanted to do for v2. However, @at-wat and I are still working on some improvements, so I'd like to hold off a bit before we tag an actual v2. I'll tag a new rc after the weekend, and unless something big comes up after that we can move to actually releasing v2.

[Sean-Der]

@daenney @at-wat I am all for announcing/releasing!

It would be great to get something on twitter, we always get new eyes on the project so that is exciting :)

[daenney]

Sure. I kinda flaked on my duties here b/c $dayjob has been keeping me busy. Pandemic hasn't helped either. I'm hoping to have some time this weekend to go over one last change I want to make, and issue a new rc.

[daenney]

Tagged and released rc.8: https://github.com/pion/dtls/releases/tag/v2.0.0-rc.8

[daenney]

Question, do we drop Go 1.12 support now that 1.14 is out, and as such merge #158, or do we keep it in place for a bit longer? The annoying thing is that for x/ed25519 only on Go 1.13 does it wrap crypto/ed25519. So if we leave it in place, on Go 1.13 it'll use the now stdlib version of it, whereas on Go1.14 it'll fall back to x/crypto b/c they didn't put the build tags in place to allow for a longer transition. Kinda sucks.

I'm inclined to say we should keep Go 1.12 in play for now, given that 1.13 was only released half a year ago. That's not all that much time for projects to migrate. On the other hand, they can keep using pion/dtls up until us deciding to drop 1.12 by pinning to the commit before then.

Either way, we should probably add Go 1.14 to CI and fix any issues before we release a 2.0.0 final.

CI passes for dtls on Go 1.14: #232

[at-wat]

I'm going to make v2.0.0-rc.9 to fix a problem with pion/webrtc pion/webrtc#1092.

[daenney]

I'd like to tag v2.0.0 on Tuesday the 31st of March.

I'm going to break Go 1.12 support, and as such merge #158. Without at least Go 1.13 crypto/x509 MarshalPKCS8PrivateKey() can't use ed25519 keys which stops us from being able to complete End-to-End testing.

If people are unhappy with this, I can do the following instead:

• Tag v2.0.0 without merging Revert "Replacing crypto/ed25519 with compatible wrapper" #158
• Tag v3.0.0 with merging Revert "Replacing crypto/ed25519 with compatible wrapper" #158

Let me know if there's any objections @at-wat @Sean-Der, and which of the two options you prefer.

[Sean-Der]

I say we break 1.12, if users need to support older versions they can pin still at least!

It just adds a burden on us to support it (and that time could be better spend elsewhere) I think my vote only counts as 1/2 though. You and @at-wat do so much more then me :)

[daenney]

I'm mostly concerned about inadvertently breaking something in the webrtc parts of Pion. I have no exposure to that, trying to be careful not to cause problems for the rest 😄.

[Sean-Der]

Appreciate the thought :)

I say don't worry about it, since the public API isn't changing they can just pin to an older version! If anyone brings it up in Slack I will just tell them to pin to the last RC.

[at-wat]

I have no objection to immediately drop Go 1.12.
I'll merge pion/.goassets#15 and sync asset files.

[at-wat]

I'm going to create rc.10 pre-release. I believe it's ready for v2.0.0.

API changes (make it closer to crypto/tls)

• Replace Conn.Export() by Conn.ConnectionState() (Add ConnectionState to Conn to return State #237)
• Move ExportKeyingMaterial() from Conn to State (Move ExportKeyingMaterial to State #240)

Fix

• Fix Conn.RemoteAddr() (Fix connCtx.RemoteAddr() #247)

[daenney]

Given the Easter holidays in some parts of the world lets tag v2.0.0 on Thursday?

[igolaizola]

Given the Easter holidays in some parts of the world lets tag v2.0.0 on Thursday?

Should we wait more to tag v2.0.0?

[daenney]

I'm not aware of anything holding us up, so I think we're good to go. This whole pandemic threw me a bit of schedule and I spaced. I'll get this done this Thursday.

[daenney]

https://github.com/pion/dtls/releases/tag/v2.0.0

[glerchundi]

Fantastic team work!!!

[at-wat]

Thanks for your work!
I'll add the details of the security fixes to the release note.