Bug 435320
| Summary: | gpgsm needs a buildreq of libgcrypt > 1.2.3 (maybe up to 1.4.0) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matthew Miller <mattdm> |
| Component: | gnupg2 | Assignee: | Rex Dieter <rdieter> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 9 | CC: | nalin |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-10-21 13:55:44 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 435770 | ||
| Bug Blocks: | |||
|
Description
Matthew Miller
2008-02-28 17:50:07 UTC
Sure, np. I'll double-check all the other minimal requirements while I'm at it... This one's particularly tricky because the buildreq isn't actually libgcrypt, but rather gpg2 (dynamically) linked against a minimal version of that library. So there's no libgcrypt listed as a req at all, currently. Right, looking closer, these errors are coming form gpgsm, which is part of gnupg2. Reassigning. While we're at it, is the (stock) combo of gnupg2/gpgme in EPEL already insufficient? Well, except, gnupg2 builds and works fine with the older libgcrypt. It's just missing functionality. An updated libgcrypt provides the functionality to gpg2 which is needed to build gpgme. So I thinking having the buildreq in the gpgme spec really does make sense. Maybe with a comment explaining what's going on. afaict, gpgme builds fine (with the latest rawhide commit I just made), it's just the post-build tests that fail. I'll go confirm that now myself to be sure. Including such a comment in gnupg2 would make sense, tho now I'll have to figure out exactly what that missing functionality *is* exactly. I'm a bit concerned that the failure of the tests is legitimate and that disabling them just patches over the problem, which will lead to more perplexing problems down the road (at least on RHEL5/CentOS5 -- with Fedora, of course, we already have the new libgcrypt so it's academic). Anyway, I'm removing the EasyFix keyword from this bug. :) OK, comment added to gnupg2 specfile. My own quick-n-dirty tests showed that upgrading libcrypt-1.2.3 -> 1.2.4 made no difference here. Matthew, I share your concerns. I'll ask upstream to see what they have to say (about the libgcrypt, gnugp2/gpgme interdependency) Nalin, would it be too unreasonable to look into providing libgcrypt >= 1.4.0 for RHEL5? :) It would be great help to provide a more fully functional gnupg2/gpgme combo. > Nalin, would it be too unreasonable to look into providing libgcrypt >= 1.4.0
> for RHEL5? :) It would be great help to provide a more fully functional
> gnupg2/gpgme combo.
FWIW, they're both libgcrypt.so.11, and in our very limited testing so far,
nothing has broken yet. :)
Updating to 1.2.4 seems to do the trick for me, actually. That release added 1.2.840.113549.1.1.11 as a recognized OID for SHA256, and not having it there appears to cause the "unknown hash algorithm" errors we're seeing. Can you double-check whether or not 1.2.4 works for you? (I ask because 1.2.4 is at perceived as a much smaller jump than 1.4.0.) I can't check immediately, but I'm willing to trust you. :) Updated comment in specfile: # libgcrypt-devel >= 1.2.4 highly recommended # see http://bugzilla.redhat.com/435320 BuildRequires: libgcrypt-devel => 1.2.2 #Requires(hint): libgcrypt >= 1.2.4 and a newer libgcrypt is coming to a rhel near you soonish (bug #435770). Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |