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... > 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. 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... 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? Cheers, François [1] https://jedisct1.github.io/minisign/ _______________________________________________ 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
