On Tue, 2024-09-10 at 12:26 +0200, Neal Gompa wrote: > On Tue, Sep 10, 2024 at 12:20 PM Daniel P. Berrangé > <berrange@xxxxxxxxxx> wrote: > > > > On Tue, Sep 10, 2024 at 12:14:58PM +0200, Neal Gompa wrote: > > > On Fri, Sep 1, 2023 at 6:11 AM Neal Gompa <ngompa13@xxxxxxxxx> > > > wrote: > > > > > > > > I'm bumping this thread again to ask if we can make everyone's > > > > lives > > > > easier by dropping all the hobbling we do today to OpenSSL, > > > > nettle, > > > > etc.. We *definitely* don't need it now at this point, so it's > > > > just > > > > needless work that creates a lot of second-order pain for > > > > people (such > > > > as library bindings for other programming languages). > > > > > > The annual bump on this thread to once again ask if we can make > > > progress on this issue. It's a pain and I really don't think we > > > have > > > any reason to keep doing it anymore. > > > > It appears the maintainers of openssl & nettle have *already* > > removed > > hobbling from Fedora > > > > In netle dist-git: > > > > commit 478b2083882071d9102297b4f0c022f65d567b1e > > Author: Daiki Ueno <dueno@xxxxxxxxxx> > > Date: Thu Aug 22 14:25:26 2024 +0900 > > > > Switch from hobbling to patching to disable algorithms > > > > Previously, certain algorithms, such as smaller ECC curves, > > were > > "hobbled" using the hobble-nettle script. It is now allowed to > > include > > the algorithm implementation in the source package, though we > > still > > want to disable them at build time. > > > > This patch switches to using a patch-based approach to disable > > them. That way, the packaging process is simplified as well as > > the > > integrity of upstream release can be checked using %gpgverify. > > > > Signed-off-by: Daiki Ueno <dueno@xxxxxxxxxx> > > > > > > And in openssl dist-git: > > > > commit 477bb5e652b21c76dccaf690d2327af8f86bd16f > > Author: Sahana Prasad <sahana@xxxxxxxxxx> > > Date: Tue Mar 14 17:07:58 2023 +0100 > > > > - Upload new upstream sources without manually hobbling them. > > - Remove the hobbling script as it is redundant. It is now > > allowed to ship > > the sources of patented EC curves, however it is still made > > unavailable to use > > by compiling with the 'no-ec2m' Configure option. The > > additional forbidden > > curves such as P-160, P-192, wap-tls curves are manually > > removed by updating > > 0011-Remove-EC-curves.patch. > > - Apply the changes to ec_curve.c and ectest.c as a new > > patch > > 0010-Add-changes-to-ectest-and-eccurve.patch instead of > > replacing them. > > - Modify 0011-Remove-EC-curves.patch to allow Brainpool > > curves. > > - Modify 0011-Remove-EC-curves.patch to allow code under > > macro OPENSSL_NO_EC2M. > > ┊ Resolves: rhbz#2130618, rhbz#2141672 > > > > Signed-off-by: Sahana Prasad <sahana@xxxxxxxxxx> > > Right, but that's still hobbling by other means. I'm asking for us to > consider not doing even *that* anymore. In 2015-12-14 was written this [1] I don't see a way to workaround it [1] https://bugzilla.redhat.com/show_bug.cgi?id=1067697#c3 I would view enabling EC curves smaller than 256 bits as a security regression. So I am wontfixing this bug. https://bugzilla.redhat.com/show_bug.cgi?id=1067697#c4 +1 to the WONTFIX They are too weak to support. And since most applications have no way to control which ones are enabled, we would need to enable them by default too, that would be serious security regression (even 256 bit curves have a shadow of doubt on them). Enabling them will bring serious security issues with little to no additional compatibility. -- Sérgio M. B. -- _______________________________________________ legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-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/legal@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
