This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 435320 - gpgsm needs a buildreq of libgcrypt > 1.2.3 (maybe up to 1.4.0)
gpgsm needs a buildreq of libgcrypt > 1.2.3 (maybe up to 1.4.0)
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gnupg2 (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
:
Depends On: 435770
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-28 12:50 EST by Matthew Miller
Modified: 2008-10-21 09:55 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-21 09:55:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Matthew Miller 2008-02-28 12:50:07 EST
We trying to rebuild gpgme from rawhide on CentOS 5, and came across this.
RHEL5/CentOS includes libgcrypt-1.2.3-1; rawhide has libgcrypt-1.4.0-2. If you
try to build gpgme with only the former installed, you'll get this:

  gpgsm: keybox `./pubring.kbx' created
  gpgsm: importing common certificates `/usr/share/gnupg/com-certs.pem'
  gpgsm: unknown hash algorithm `1.2.840.113549.1.1.11'
  gpgsm: self-signed certificate has a BAD signature: General error
  gpgsm: basic certificate checks failed - not imported
  gpgsm: unknown hash algorithm `1.2.840.113549.1.1.11'
  gpgsm: self-signed certificate has a BAD signature: General error
  gpgsm: basic certificate checks failed - not imported
  gpgsm: unknown hash algorithm `1.2.840.113549.1.1.11'
  gpgsm: self-signed certificate has a BAD signature: General error
  gpgsm: basic certificate checks failed - not imported
  gpgsm: total number processed: 13
  gpgsm:               imported: 10
  gpgsm:           not imported: 3
  make[3]: *** [pubring.kbx] Error 1

Updating libgcrypt to the rawhide release 1.4.0-2 solves the problem.

Since this is a requirement for the latest Yum, I think it's not just going to
be us here trying to rebuild for CentOS5/RHEL5, so we can save other people some
headache by including the buildreq. Thanks!
Comment 1 Rex Dieter 2008-02-29 21:07:20 EST
Sure, np.  I'll double-check all the other minimal requirements while I'm at it...
Comment 2 Matthew Miller 2008-02-29 21:26:48 EST
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.
Comment 3 Rex Dieter 2008-02-29 21:29:22 EST
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?
Comment 4 Matthew Miller 2008-02-29 21:36:21 EST
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.
Comment 5 Rex Dieter 2008-02-29 21:44:39 EST
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.
Comment 6 Matthew Miller 2008-02-29 22:06:04 EST
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. :)
Comment 7 Rex Dieter 2008-02-29 22:17:03 EST
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.  
Comment 8 Matthew Miller 2008-02-29 23:05:54 EST
> 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. :)
Comment 9 Nalin Dahyabhai 2008-03-03 13:55:14 EST
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.)
Comment 10 Matthew Miller 2008-03-03 14:03:15 EST
I can't check immediately, but I'm willing to trust you. :)
Comment 11 Rex Dieter 2008-05-05 08:25:13 EDT
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).
Comment 12 Bug Zapper 2008-05-14 01:41:16 EDT
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

Note You need to log in before you can comment on or make changes to this bug.