Skip to content

Prepare 1.12.0 release #79

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

Merged
merged 4 commits into from
May 7, 2025
Merged

Prepare 1.12.0 release #79

merged 4 commits into from
May 7, 2025

Conversation

djc
Copy link
Member

@djc djc commented May 1, 2025

Release notes

  • Implement Zeroize for private key types
  • Add algorithm identifiers for ML-DSA signing algorithms

@djc djc requested review from cpu and ctz May 1, 2025 09:07
@dare3path

This comment was marked as outdated.

@djc
Copy link
Member Author

djc commented May 1, 2025

Yeah -- so apparently this is a major change, so I guess we can't just add it like this. And I think it's also probably not worth doing a 2.0 only for this?

@ctz
Copy link
Member

ctz commented May 1, 2025

Yeah I'm afraid this alone doesn't motivate a 2.0 for me :(

For now we could keep the Zeroize impls, and downstream users can write Zeroizing<PrivateKeyDer<'_>>. That is a bit unsatisfying though.

@djc
Copy link
Member Author

djc commented May 1, 2025

For now we could keep the Zeroize impls, and downstream users can write Zeroizing<PrivateKeyDer<'_>>. That is a bit unsatisfying though.

So one goal in this PR was to avoid having zeroize types/traits in the public API. Do you think we should allow those in order to enable the use of stuff like Zeroizing? Alternatively, I suppose we could provide our own Zeroizing type wrapper that handles this, while still hiding the dependency?

@ctz
Copy link
Member

ctz commented May 6, 2025

On the assumption we don't want zeroize in the public API, I think the latter is the best way to go -- specifically provide some zeroizing newtypes (maybe generic) that hold a PrivateKey* value. That means downstream users need to opt-in to the drop behaviour change, but that is the situation we are in.

@djc djc force-pushed the zeroize-on-drop branch from b50af82 to 3c3f1e1 Compare May 7, 2025 09:58
@djc djc changed the title Zeroize on drop Prepare 1.12.0 release May 7, 2025
@djc djc force-pushed the zeroize-on-drop branch from 3c3f1e1 to 68a7dbb Compare May 7, 2025 10:01
@djc djc added this pull request to the merge queue May 7, 2025
Merged via the queue into main with commit 4b52db8 May 7, 2025
16 checks passed
@djc djc deleted the zeroize-on-drop branch May 7, 2025 13:02
@djc
Copy link
Member Author

djc commented May 7, 2025

  • Published rustls-pki-types v1.12.0 at registry crates-io
  • [new tag] v/1.12.0 -> v/1.12.0
  • Release notes

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.

4 participants