This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/5043

@thillux @ulrikstrid Could you please take a look?

@thillux @ulrikstrid Could you please take a look?

I'm a bit low on bandwidth currently, I can try to find some time next week for a review.

Ideally we should have a better way to load providers and engines so that we don't have to create custom packages when we want to add more providers.

No worries, whenever you're free!

Ideally we should have a better way to load providers and engines so that we don't have to create custom packages when we want to add more providers.

I'm not sure how this would be possible? The best thing I can think of is an "empty" default openssl package, for example named openssl_with_providers without any providers that it's possible to override later.

I'll probably have time again to look at this starting next week. Is there any upcoming user of this in nixpkgs? Are there any other OpenSSL providers besides TPM 2.0, esdm and oqs we can build/test this with?

I'm also not really happy with introducing a default package for every provider combination. Nevertheless, using providers should be made easier 👍.

We probably should update master/unstable to OpenSSL 3.4.0 on the go, as this adds more CLI options for testing key encapsulation schemes.

Is there any upcoming user of this in nixpkgs?

I'm not aware of any people in particular, but given that oqs-provider and liboqs were added recently, it does seem like there's at least some people who would find this useful.

Are there any other OpenSSL providers besides TPM 2.0, esdm and oqs we can build/test this with?

with-providers should work with any providers, although I don't know of any others

I'm also not really happy with introducing a default package for every provider combination.

Me neither :( unfortunately I don't know if there's a better way; Nix forces us to declare everything about the package, right?

We probably should update master/unstable to OpenSSL 3.4.0 on the go

Do you mean that should happen in this PR?

I'm also not really happy with introducing a default package for every provider combination.

Ideally we should have a providers or something that we can pass a list of providers to add. openssl.override { providers = [ ... ]

We probably should update master/unstable to OpenSSL 3.4.0 on the go

Do you mean that should happen in this PR?

No, I opened #372733 for this.

Sorry, the PR accidentally closed after I force pushed the wrong commit!

I'm also not really happy with introducing a default package for every provider combination.

Ideally we should have a providers or something that we can pass a list of providers to add. openssl.override { providers = [ ... ]

Ah, I didn't realize that the problem was the extra provider package instead of the override being available on the normal openssl package. I've changed the code to match this suggestion, so now anyone can add their own providers with openssl.override

Perhaps a way to configure openssl similar to the way different BLAS/LAPACK implementations are selected would be a good way to go about it?

Perhaps a way to configure openssl similar to the way different BLAS/LAPACK implementations are selected would be a good way to go about it?

Reading over it, this implementation seems similar: somebody can use openssl.override { proivders = []; } with their own packages, similar to how someone can use lapack.override { lapackProvider = ... }

The only issue I have is with the handling of the config, which is not the nicest way to handle the config, but because it's a nonstandard format I don't see a better way.

The only issue I have is with the handling of the config, which is not the nicest way to handle the config, but because it's a nonstandard format I don't see a better way.

Is it not just an INI with a global section?

Is it not just an INI with a global section?

It is, so I guess you could say it's standard (even though the INI format doesn't have a formal specification), but it doesn't seem like there's a way to convert to INI in Nix. It seems like there's only support for TOML.

There is! :) Check out lib.generators.toINIWithGlobalSection :)

@spacekitteh Thanks for the recommendation! Do you know if there's a way to go the other way from INI -> Nix? Without it, modifying the config seems like it'll be just crudely appending to whatever's already there, or sed replacement. Another option might be to rewrite the entire config in Nix, which I feel is a significantly worse approach.

Hi everyone, I've updated the PR to include the INI format generator, and I think it's ready for review. If there's anything you would like me to change, I'd be happy to do so.

@thillux @ulrikstrid If you're busy no worries, but is there anything you'd like me to change/fix up?