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

0.102 release planning #159

Closed
13 tasks done
Tracked by #1435
djc opened this issue Aug 31, 2023 · 10 comments
Closed
13 tasks done
Tracked by #1435

0.102 release planning #159

djc opened this issue Aug 31, 2023 · 10 comments

Comments

@djc
Copy link
Member

djc commented Aug 31, 2023

@cpu
Copy link
Member

cpu commented Sep 7, 2023

Added a few more items to the list (most of which are already merged).

@cpu
Copy link
Member

cpu commented Sep 20, 2023

Almost there 🎉

@djc djc pinned this issue Sep 21, 2023
@djc
Copy link
Member Author

djc commented Sep 21, 2023

I think we should defer releasing the final version of this until the final rustls release is also ready, in order to avoid creating more semver-incompatible version branches (that we have to maintain according to our maintenance policy) if it still turns out that we have some churn in the API we want for rustls.

@cpu
Copy link
Member

cpu commented Sep 21, 2023

That sounds good to me.

@djc
Copy link
Member Author

djc commented Sep 22, 2023

Thought about the requirements before release some more, added 3 items.

@cpu
Copy link
Member

cpu commented Sep 28, 2023

Push RevocationOptions into pki-types to avoid public webpki type in rustls API?

We chatted about this one in a Discord thread. Making this change will require moving a lot of types into pki-types, most of which are actually specific to webpki and don't look like they would generalize well to other verifiers. There are some additional downsides to this approach as well, like having to un-seal the CertRevocationList trait.

The line-item mentions leaking types into the rustls API but presently the webpki revocation types only appear in the webpki verifier bits that are already specific to webpki. The rustls/rustls#1430 issue that may have motivated this change can be accomplished by wrapping the webpki verifier so it doesn't seem like it would justify the work involved.

In sum: I think we're going to table this idea for the 0.22 release and encourage 1430 be solved with other workarounds.

@ctz
Copy link
Member

ctz commented Nov 20, 2023

Push ServerName type into pki-types so it can be shared with rustls?

That would include DnsName I suppose, so we could remove the duplication there (though it has a modest amount of behaviour for a crate that is so far mostly structural).

I guess moving this up could theoretically be a non-breaking change? In the sense that both webpki and rustls could reexport the moved type? That is assuming the type we move is a superset of webpki::DnsName and rustls::DnsName?

@ctz
Copy link
Member

ctz commented Nov 30, 2023

Aside from some release engineering (taking pki-types to 1.0, editing versions here) I think this is done?

@djc
Copy link
Member Author

djc commented Nov 30, 2023

Yeah, I think so!

@ctz
Copy link
Member

ctz commented Nov 30, 2023

https://crates.io/crates/rustls-webpki/0.102.0

@ctz ctz closed this as completed Nov 30, 2023
@djc djc unpinned this issue Aug 27, 2024
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

No branches or pull requests

3 participants