Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1036466
Summary: | Remove crypto throttle | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Peter Backes <rtc> |
Component: | gnupg2 | Assignee: | Tomas Mraz <tmraz> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | bcl, fedora, jamielinux, mjg, rdieter, slukasik, tmraz |
Target Milestone: | --- | Keywords: | FutureFeature, Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | gnupg2-2.2.0-1.fc26 gnupg2-2.2.0-1.fc27 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-09-08 03:49:55 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: |
Description
Peter Backes
2013-12-02 04:35:25 UTC
While the change is trivial, it is an enhancement that should best be done upstream, wouldn't it? Also: With the new ECC initiative in Fedora, won't we be able to use ECC keys? Or are they still banned by RH legal? (In reply to Michael J Gruber from comment #1) > While the change is trivial, it is an enhancement that should best be done > upstream, wouldn't it? Yes, I agree. > Also: With the new ECC initiative in Fedora, won't we be able to use ECC > keys? Or are they still banned by RH legal? The support for ECDSA/ECDH is only in the development branch of gnupg upstream. (In reply to Michael J Gruber from comment #1) > While the change is trivial, it is an enhancement that should best be done > upstream, wouldn't it? According to http://gagravarr.livejournal.com/137173.html upstream is refusing to make that change, with strange justifications: "they think that for most people going to 8192 bits will just make things slower, without delivering much more security, so they feel that anyone who wants a longer key should have to think about it, and explicitly enable it themselves." I can confirm that upstream is refusing to make this change because of performance issues. I think when it comes to security performance must not matter. This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. Bug still present. Please reopen and change version to F24. Depends if fedora's maintainer(s) agree with upstream (close->wontfix) or not (patch around it). I do not agree fully with the upstream reasoning as there might be valid reasons to use large keys, on the other hand I am not so sure it is worth the effort to patch it downstream. If someone provided such patch (including documentation changes) I would apply it though. People have done this before: https://deekayen.net/large-gpg-keys https://lists.gnupg.org/pipermail/gnupg-devel/2014-October/028930.html gnupg2-2.2.0-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-22bee61e57 gnupg2-2.2.0-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-a43ed4a971 This bug report is marked as modified, but I don't see any indication that this bug is really fixed. Neither the upstream release announcement nor its NEWS or README file indicate any change related to this bug report, as does the Fedora spec file on https://src.fedoraproject.org/rpms/gnupg2/commits/master. I think there has been a mistake here. The Fedora spec contains the change and it enables the upstream large RSA key support = 8192 bit keys. We will not deviate from upstream in enabling even larger keys. (In reply to Tomas Mraz from comment #14) > The Fedora spec contains the change and it enables the upstream large RSA > key support = 8192 bit keys. We will not deviate from upstream in enabling > even larger keys. Ok, thanks for the hint and sorry for the noise. gnupg2-2.2.0-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-22bee61e57 gnupg2-2.2.0-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-a43ed4a971 gnupg2-2.2.0-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. gnupg2-2.2.0-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report. |