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

provider filename ibmca-provider.so vs ibmca.so #93

Open
sharkcz opened this issue Jan 10, 2023 · 3 comments
Open

provider filename ibmca-provider.so vs ibmca.so #93

sharkcz opened this issue Jan 10, 2023 · 3 comments

Comments

@sharkcz
Copy link
Contributor

sharkcz commented Jan 10, 2023

Currently the provider filename is ibmca-provider.so, but would it be possible to use ibmca.so instead, which is more obvious in my opinion?

openssl speed -engine ibmca
vs
openssl speed -provider ibmca-provider
The 'provider' string looks redundant ...

Not sure if it was causing some filename conflicts previously when both engine and provider were built, but with switching to using provider exclusively in systems with openssl >=3, it shouldn't be an issue.

@ifranzki
Copy link
Contributor

The problem is that when you build both, engine and provider and then do a make install, then both are installed into the same directory (i.e. /usr/local/lib). So they can't be name the same obviously.

Sure, if you enable only engine or only provider, then that's not a problem, you can then specify --libdir to point to the OpenSSL modules or engine directory right away, as described in README.md.

The other problem is that changing the name would have a hit in the OpenSSL configuration file:

[ibmca_sect]
identity = ibmca
module = ibmca-provider.so  <---- see here
activate = 1

So I guess its quite impossible to silently change this without the users requiring some action....
We (you) could certainly create a symlink named ibmca.so to point to ibmca-provider.so in the OpenSSL modules directory during RPM installation..... That way you would be able to use the short name if wanted.

@sharkcz
Copy link
Contributor Author

sharkcz commented Jan 11, 2023

Thanks for the reply, it aligns with my understanding. Although engine or provider is becoming an "exclusive or", right?

I think adding the short symlink would be a user-friendly addition ...

@ifranzki
Copy link
Contributor

Although engine or provider is becoming an "exclusive or", right?

At some point in time probably yes, but currently OpenSSL 3.0 still supports engines (with some limitations though, i.e. only for applications that use the old APIs, not for applications that use the OpenSSL 3.0 provider specific APIs).

I think adding the short symlink would be a user-friendly addition ...

Certainly, but it would be the distribution partner who needs to do so.

Please be aware that the -provider options of the openssl command is probably not the recommended way to configure a provider. Users should add the providers they want to use to their OpenSSL config file, and set the default_properties in the alg_section as needed so that the applicating transparently fetch the algorithms from the providers.

[openssl_def]
providers = provider_sect
alg_section = evp_properties
...
[evp_properties]
default_properties = ?provider=ibmca

Fetching algorithms strongly depends on the property queries used by the applications (or the default property query). Just loading a provider may not have any effect at all. I would assume that openssl speed -provider ibmca-provider without specifying a property query like -propquery ?provider=ibmca will not use the IBMCA provider for anything, unless you have configured it in your OpenSSL configuration file as shown above (If configured in the OpenSSL config file, you should not need to specify the -provider option at all though).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants