Skip to content

Conversation

@bal-e
Copy link
Contributor

@bal-e bal-e commented Jun 30, 2025

  • ring and openssl now enable a shared unstable-crypto-backend feature, which is used internally to test whether a common backend is available.

  • Examples / doc tests in crypto, relying on crypto::common, have been moved to the submodule to avoid needing more cfg magic.

  • unstable-crypto now enables std; this requirement was previously undetected (and the CI will be adjusted to try to catch more of these over time), but compilation would fail without it.

  • unstable-sign and unstable-validator now fail to compile if ring and/or openssl are not enabled. Previously, those modules would remain configured out. Its status as a breaking change is debatable, but in any case it only affects unstable features.

- 'ring' and 'openssl' now enable a shared 'unstable-crypto-backend'
  feature, which is used internally to test whether a common backend is
  available.

- Examples / doc tests in 'crypto', relying on 'crypto::common', have
  been moved to the submodule to avoid needing more 'cfg' magic.

- 'unstable-crypto' now enables 'std'; this requirement was previously
  undetected (and the CI will be adjusted to try to catch more of these
  over time), but compilation would fail without it.

- 'unstable-sign' and 'unstable-validator' now fail to compile if
  'ring' and/or 'openssl' are not enabled.  Previously, those modules
  would remain configured out.  Its status as a breaking change is
  debatable, but in any case it only affects unstable features.
@bal-e bal-e requested a review from Philip-NLnetLabs June 30, 2025 13:43
@bal-e bal-e self-assigned this Jun 30, 2025
@bal-e
Copy link
Contributor Author

bal-e commented Jun 30, 2025

This should also fix the CI failure in #547.

@Philip-NLnetLabs
Copy link
Member

Can we rename it to 'internal-crypto-backend' or any other convention to show that something is not to be used?

@partim
Copy link
Member

partim commented Nov 6, 2025

I think having a separate prefix for internal features would indeed be good. I don’t think we need a separate prefix for internal unstable features, though, given that they not user-facing, anyway.

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.

3 participants