Open pattivacek opened 2 years ago
Actually, these might be worse than just warnings. I'm getting consistent failures in PKCS12_parse
that are preventing me from provisioning. @cajun-rat @mike-sul have you seen this?
I'm on Debian 11, which still uses 1.1.1
Our dev&test containers/env is still on OpenSSL 1.1.1f.
+1 Same issue on arch linux
An add_definitions(-Wno-deprecated-declarations)
to the project solves the declaration warnings momentary
I think the best way to solve this problem is to force users of libp11 to install it as an engine on their system, and configure openssl to use it. Then using the high level EVP API from OpenSSL should be fine. That would reduce the complexity of the project. Not sure if it works but worth a try
I'm on Debian 11, which still uses 1.1.1
I've just upgraded to Debian 12, which does use OpenSSL 3 :( Turning off the warnings-as-errors gives me a build that fails quite a lot of unit tests, so I agree, there is something bigger that needs looking into here.
I found the OpenSSL 3 migration guide . It looks like a good chunk of crypto.cc will need updating to move away from the deprecated APIs, but on the bright side at least most of the crypto stuff is already behind a wrapper.
I think I've figured out why removing the warning about deprecated declarations isn't enough. OpenSSL now doesn't load 'legacy' providers by default. This rather horrible static-initialization hack on the end of crypto.cc gets most of the tests passing on my machine.
class CryptoOpenSSlInit {
public:
CryptoOpenSSlInit() {
OSSL_PROVIDER *legacy = OSSL_PROVIDER_try_load(NULL, "legacy", 1);
if (legacy == nullptr) {
std::cout << "Warning: could not load 'legacy' OpenSSL provider";
}
OSSL_PROVIDER *default_p = OSSL_PROVIDER_try_load(NULL, "default", 1);
if (default_p == nullptr) {
std::cout << "Warning: could not load 'default' OpenSSL provider";
}
}
};
CryptoOpenSSlInit const CryptoIniter{};
I'm still thinking that biting the bullet and re-writing crypto.cc to use the new APIs is the better solution.
I'm still thinking that biting the bullet and re-writing crypto.cc to use the new APIs is the better solution.
Yeah, I agree. Your trick looks fine for a dirty hack but that's not The Way.
I think we might have a problem supporting key storage in PKCS#11 and not using the deprecated APIs. The cause is that the 'engine' APIs are used to talk to the HSM via PKCS#11, and the replacement 'provider' APIs would need an alternative to the 'PKCS#11 engine library' that talks the provider API rather than the engine API. There are such things on Github (example) but I can't find one in Debian stable right now.
I think the option space is:
-Wno-deprecated-declarations
. Right now I think we should go with the first. I'm not a big fan of differing code paths under #defines
(option 2), and building 3rd party libraries is an upgrade treadmill.
I agree. If the deprecated APIs still work, there's no urgency to find a new solution, and my memory of the initial PKCS#11 support was that it was quite tedious and took a lot of effort to get working just right. I wouldn't want to go through that again with a library that might disappear or get replaced by something better down the line. Obviously using deprecated APIs isn't great but I think the ecosystem hasn't quite caught up yet.
I recently updated my OS to 22.04, which uses openssl-3 by default. That's excellent, but we get a bunch of deprecation warnings now, such as:
... and so on. There are also a couple boost errors I'm seeing (with 1.74.0) like this: