search

FlorianUekermann / rustls-acme

Apache License 2.0
136 stars 27 forks source link

Release 0.4.0 #28

Closed FlorianUekermann closed 2 years ago

FlorianUekermann commented 2 years ago

I just published 0.4.0-beta2 on crates.io and would like to release 0.4.0 in a few days. The main changes are:

The high level API did not change, besides using types from futures-rustls instead of async-rustls. This makes the low level API less opinionated and allows the user to do anything they want with incoming connections. This enables many new usecases via the low level API: -Using alpn with non-validation connections -Mixing other certificate sources by wrapping custom resolvers around the the rutsls-acme resolver -Client authentication

Feedback and test results are much appreciated. @joshtriplett : You may want to test how ergonomic the changed API is on your side. You may want to have a look at the axum features as well. Maybe there's something similar you would like to upstream.

casey commented 2 years ago

I just switched out my acceptor for the one in 0.4.0-beta2, and it seems to be working will. It's deployed in prod and on our test instance.

casey commented 2 years ago

I think this can be closed, since it looks like 0.5.0 has been released.

joshtriplett commented 1 year ago

@FlorianUekermann I understand why you switched to futures-rustls (I think), but sadly, that's going to make it very difficult to use in the tide-acme project in its current form, since tide-acme integrates with tide-rustls which requires async-rustls.

The only way I'd be able to address that is by fully replacing tide-rustls as well, which would require handling the rest of the TLS details that tide-rustls handled.

FlorianUekermann commented 1 year ago

Yes, that's unfortunate. I'm a little fuzzy on the details atm, because I switched such a long time ago. I see three ways forward:

  1. Figure out if we can convert the types. I suspect that's not that hard. I think async-rustls is just missing a From impl we can use.
  2. I could switch back. This is only an option if async-rustls has caught up in term of features (not entirely sure anymore what exactly was missing). futures-rustls is a lot more popular though.
  3. Given how much more popular futures-rustls has become and how redundant async-rustls and futures-rustls are (is that correct?), maybe it is time to explore consolidating by switching over on the tide-rustls side.

We should really try to find a solution for this. Let's use #46 for further discussion.