https://bugzilla.redhat.com/show_bug.cgi?id=2394931
--- Comment #25 from Carlos Rodriguez-Fernandez <[email protected]> --- > Unfortunately your link at [1] seem to have lost clarity on this over time, > in any case the meaning of the link is that if you introduce a crypto library > package that does not conform to crypto policies you have to ask for an > exception by the Fedora Packaging Committee which is informed by the Crypto > team on what is acceptable or not, then they can decide any way they want and > override the recommendations of the Crypto Team. Would this apply to a major release update of an existing package? The only reason it is a new package is because of compatibility. A leaf package wouldn't even need a new review. > Botan still does not properly support Crypto Policies therefore at each new > package review I will keep objecting on its inclusion in Fedora. I also have > sever reservations on the quality of this library and therefore its inclusion > as a general use library. Regarding its quality, I understand your team does a thorough testing but, as example, you say OpenSSL is solid, but if you compare the CVE trends in OpenSSL[1] vs Botan[2], Botan doesn't come out too bad. Yes, those side channel vulnerabilities are there, but so it is the case of OpenSSL with CVE-2022-4304 or CVE-2024-13176, for example. Botan 3 has improved the code to ensure O(1) time complexity on operations in comparison with Botan 2. I did backport the last two timing kind of vulnerabilities in Botan from 3 into 2, CVE-2024-50382 and CVE-2024-50383. For one of them, I did have to develop the fix beyond simple backporting, and the upstream developer was prompt to review it and bless it. The project is very active. In addition to that, there is at least one institution, i.e., German Federal Office for Information Security, that contributed with docs and tests to the project and recommends it for apps with increased security requirements after auditing was done. That is just another piece that shows the numbers of eyes on the project. I understand that in spite of all of that, it is an TLS implementation out of management reach by your team. How does your team do with projects like golang apps that use the golang own tls implementation? Can it be done the same way for these non-openssl libs? > I understand there are a couple of other applications that were added just > because botan was let through I do see more from the positive impact perspective, that because Botan was available in Fedora Linux like in other major distros, the packagers were able to add those applications to Fedora Linux with minimal effort. > We curate the CA certificate store so only vetted CAs are allowed on the > system. If you are referring to the system cert, yes, Botan 2 and 3 does use the Fedora system cert CA now. It was using the RedHat path, but I submitted a patch to update it to /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem [3] and also patched our botan2. Regarding ciphers, Botan does have a policy that can be configured at build time[4], and the file location is passed with the --module-policy option. I wonder if there is something that can be done with that in that respect. Thank you for taking the time to explain all of this. I'm learning more about the crypto team's efforts and vision which I definitely appreciate. [1] https://www.cvedetails.com/vendor/217/ [2] https://www.cvedetails.com/vendor/15841/ [3] https://github.com/randombit/botan/blob/14e54e7a15ae2392fc4f010bb39830cc9d50365d/configure.py#L3212 [4] https://github.com/randombit/botan/tree/master/src/build-data/policy -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2394931 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202394931%23c25 -- _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
