Add openssl support as an alternative to mbedtls - #2811
Conversation
|
Thanks for the PR! However, we used to use OpenSSL in the past before I was made aware that OpenSSL is incompatible with GPL code: #173 Edit: It's possible that that's outdated information, OpenSSL 3 apparently changed the license |
|
openssl changed to apache 2.0 which works with gpl3/gpl2-or-newer but not gpl2. libressl (bsd's openssl 1.0 fork) also has this issue. wolfssl is an alternative that does work within the license requirements though. |
|
also, CBC is the most common AES cipher block mode. having the openssl implementation explicitly disable that mode is very problematic. though a viable alternative is needed as mbedtls, unlike openssl, flirts with the idea to remove ciphers. |
|
does crypto++ satisfy the same scope as mbedtls? that one could work as a suitable alternative. |
|
fwiw, I'm also completely fine with staying with mbedtls. I never had any issues with mbedtls upgrades |
TL;DR this will greatly reduce the amount of effort downstream in Fedora and other distros. Well, I think for this statement to be true, it depends on how it get's deployed. If you're just building a giant monolith, it's fine. But downstream in packages, they try and decouple the dependencies, and a big one to decouple is the crypto library for a couple of reasons:
mbedtls isn't the best for those scenarios. First, it's designed for monolithic embeded application usage, so the APIs and ABIs change at whim. For instance, in one API stable version, they will re-order structs breaking the ABI. I don't think we remove mbedtls, since it works well for the monolith model, but for Linux distro users, where the "default" crypto provider is OpenSSL, it would be nice to have support here. mbedtls will eventually be removed from Fedora, which means imhex would have to bundle it in the package, which means updates have to be done per-package. In retrospect, and I helped to create this problem, mbedtls should never have made it into the package managers. |
That's why it's in draft right now. So, @connor-cihula's investigation has found that many modes are broken. So we can do one of two things here:
Looking for the community to weigh in, also not sure if anyone is aware of this and fixes are inbound. |
|
What's the solution for projects, like ImHex, that can't use the "default" crypto provider though due to its license? I chose mbedTLS in part because of its very permissive license. As it is right now, I can't accept this PR without breaking the GPL
Are they broken in mbedTLS or in ImHex? If it's the latter, I'd absolutely rather fix them |
IIUC, within ImHex, do you know of any open bug reports or PRs incoming? I see these: but I have no idea if it's related. |
They either use mbedTLS, WolfSSL, gnuTLS, Botan, or use system cryptography primitives via BCrypt on windows, CryptoKit on macOS, AF_ALG on Linux and OCF on *BSD. |
|
I was specifically interested in what Fedora is planning to use. Since ImHex is definitely not the only GPLv2-only repo that can't use OpenSSL |
|
fedora considers openssl a system library and freely links to it under the system library exception, but not every distro agrees with that stance. |
That's fine, they can do whatever, but this is for the 75% of the linux distro world that does. Summary
Default System Crypto Library by Distribution
Breakdown of Non-OpenSSL Systems
Notes
|
|
Thank you for the summary, however that still doesn't answer my questions:
I assume this will require builds shipped by us to still always use mbedTLS since we cannot ship the OpenSSL binary and the system library exception (if that even applies here) would only apply in the case where OpenSSL is already installed on the system? |
That's good, since I was answering @neptuwunium :-p. But to answer your question...
TL;DR lets just use gnutls which is LGPLv2.1+ Sorry I thought you answered that #2811 (comment), but I see it was a bit open ended, my apologies. My answer here is not as simple as a yes or no and does not constitute legal advice in any way shape or form. But considering the readme states something to the affect of libimhex is LGPL so propriety plugins can be written, strengthens the legal case since the interface defines interoperability, not derivation. My answer would be, git does. However, this isn't a conclusive argument. You can ask 10 different license attorney's and get 10 different answers, but considering that this is a plugin designed interface, it's not shipping openssl, etc. I would say low risk. However, if that is unacceptable, something like gnutls (LGPLv2.1+) would work as well.
Correct. |
|
Oh I'm sorry :D I think GnuTLS would be a better choice for this project |
No worries.
Yes I agree. So what we will do on our end is fix the crypto algs and then add GnuTLS support. |
|
Kinda unrelated so I created #2825 to discuss in But if I understand correctly, (some of) you guys are packagers for distributions, right ? |
5 participants
Problem description
MbedTLS is prone to introducing breaking changes in minor releases. OpenSSL tends not to have this problem.
Implementation description
OpenSSL can be chosen as the crypto backend with
-DCRYPTO_BACKEND=openssl. MbedTLS remains the default, but can be explicitly set with-DCRYPTO_BACKEND=mbedtls.Screenshots
N/A
Additional things
The OpenSSL implementation refuses to attempt AES modes that MbedTLS does not implement properly.