On Fri, 2019-08-09 at 13:26 +0200, François Kooman wrote: > On 09.08.19 12:19, Petr Pisar wrote: > > An algorithm that will be obsoleted by another modern algorithm in ten years. No > > this is not how cryptographical tools should be designed. The tool and the > > singature format must be agnostic to a concrete algorithm. > > Actually. It is not designed like this, see [1] for the signature/key > format. > > This is an invalid argument. You can always found an arbitrarily old > > distribution that does not support a feature of your choice. > > Fair enough, it is not an argument against using OpenSSL, just against > using it on RHEL/CentOS 7 assuming one wants to use Ed25519 for > signatures and not RSA or ECDSA. > > > There is no explanation why. Only a "don’t use a low-level crypto library like > > OpenSSL or BouncyCastle" statement. Do you have any explanation? > > Okay, we are getting a bit off-topic here :-) > > Using a low level crypto library like OpenSSL is a bad idea for > developers. It gives them a huge foot gun. I know enough not to want to > use the OpenSSL API as a developer. I will screw it up. I'm confident I > can write an application using libsodium without the crypto > implementation being the weak part. I'm sure that's true for most (all?) > developers that are not also OpenSSL developers... Unless you are a crypographer you will screw it up anyway :-) And if you are targeting Fedora/RHEL libsodium is a no-go for now. > > Moreover, I cannot see how TLS is relevant to a code signing. > > It is not. OpenSSL is (according to the blog post linked) only the best > tool for doing TLS. For all other purposes it is not the best tool. This is sophism, what you need, if you are really writing a signing tool, is someone expert in cryptography to check your code *anyway*, because there are many, many aspects of signing you may get catastrophically wrong otherwise. And an expert will know how you should use OpenSSL correctly anyway. TL;DR: Do not think that using some new crypto library automagically makes you write correct code when cryptography is involved, always consult and use tools provided/vetted by your experts. > So > introducing something like libsodium for non-TLS purposes seems like a > good thing to do! Especially if this means dropping the OpenSSL/GnuPG > dependency... No it is not a good thing for the reasons you are providing. There may be good reasons, but writing a signing tool is not one of them for sure. And using wellknown and maintained libraries (by your distribution experts) is a better reason to use what is available than introducing a new crypto-library on the promise that it is somehow "better". > I don't know what the reasons are for arguing against libsodium for > non-TLS crypto use cases, maybe the foreseen (long term) potential costs > in case libsodium would be added to RHEL, next to OpenSSL and GnuPG? There is added maintenance cost for any new package, and crypto- libraries have a steep cost because they are more critical indeed (and fewer people can properly maintain them, I hate to cite it, but I'd like to remind you the Debian maintenance snafu a few years ago with OpenSSL that was catastrophic indeed). We already have 4 crypto-libraries in the distro, I am not against a new one if you can drop another in the process (and the process is strictly: drop before adding) Simo. _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
