Skip to content

Conversation

@simo5
Copy link
Member

@simo5 simo5 commented Sep 16, 2025

Description

Changes kryoptic (in non-fips builds) to try to load the default openssl configuration on the custom context.
Because the configuration file could be missing for "legitimate" reasons, we do not treat as fatal the failure to load the default configuration.

Fixes #319

Checklist

  • Test suite already has enough coverage for this change
  • Rustdoc string were added or updated
  • CHANGELOG and/or other documentation added or updated
  • This is not a code change

Reviewer's checklist:

  • Any issues marked for closing are fully addressed
  • There is a test suite reasonably covering new functionality or modifications
  • This feature/change has adequate documentation added
  • A changelog entry is added if the change is significant
  • Code conform to coding style that today cannot yet be enforced via the check style test
  • Commits have short titles and sensible text
  • Doc string are properly updated

This may be needed if an application tries to use ciphers the have been
moved to the legacy provider and therefore normally fetching them would
fail.

Signed-off-by: Simo Sorce <[email protected]>
@simo5 simo5 changed the title Load default config when possible Load default openssl config when possible Sep 16, 2025
Kryoptic creates a new context to avoid influencing (or being
influenced by) applications, however it should at least load the
default configuration so it conforms to things like the system-wide
crypto policy on OSs that have that feature.

Signed-off-by: Simo Sorce <[email protected]>
@Jakuje
Copy link
Contributor

Jakuje commented Sep 17, 2025

the pkcs11-provider integration test failure is a recursion when we try to load the pkcs11 provider into the kryoptic's openssl context?

@Jakuje
Copy link
Contributor

Jakuje commented Sep 17, 2025

the pkcs11-provider integration test failure is a recursion when we try to load the pkcs11 provider into the kryoptic's openssl context?

In that case, I think doing this in the kryoptic pkcs11 module is not that great idea :) But for any other users of ossl bindings, ye, this looks good to me.

@simo5
Copy link
Member Author

simo5 commented Sep 17, 2025

the pkcs11-provider integration test failure is a recursion when we try to load the pkcs11 provider into the kryoptic's openssl context?

In that case, I think doing this in the kryoptic pkcs11 module is not that great idea :) But for any other users of ossl bindings, ye, this looks good to me.

This is why I had created a new context an not loaded the default config in the first place ... sounds like we should revert this commit and rethink the strategy.

There are two reasons we wanted to load the default config:

  1. crypto-policies
  2. loading the FIPS provider when kryoptic is build with dynamic openssl bindings

Perhaps we should create a custom configuration file for kryoptic that loads just crypto-policies snippets but only the default provider. That would take care of both 1 and 2 w/o the risk of pulling in other providers that may break it?

@Jakuje
Copy link
Contributor

Jakuje commented Sep 17, 2025

That makes it much more complicated, but likely only reasonable solution.

@simo5 simo5 marked this pull request as draft September 17, 2025 15:32
@simo5 simo5 added the deferred Will be finished later label Sep 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

deferred Will be finished later

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Kryoptic should probably load the default openssl config

2 participants