Bug 435770 - update from 1.2.3 to 1.2.4 to pick up PKCS#1 OIDs
Summary: update from 1.2.3 to 1.2.4 to pick up PKCS#1 OIDs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libgcrypt
Version: 5.1
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: Ondrej Moriš
URL:
Whiteboard:
Depends On:
Blocks: 435320
TreeView+ depends on / blocked
 
Reported: 2008-03-03 19:19 UTC by Nalin Dahyabhai
Modified: 2011-01-27 12:50 UTC (History)
3 users (show)

Fixed In Version: 1.2.4-1.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-20 21:43:06 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
sample program to be built with libgcrypt (481 bytes, text/plain)
2008-03-03 19:19 UTC, Nalin Dahyabhai
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2009:0174 0 normal SHIPPED_LIVE libgcrypt enhancement update 2009-01-20 16:05:41 UTC

Description Nalin Dahyabhai 2008-03-03 19:19:48 UTC
Short discussion: 1.2.4 recognizes 1.2.840.113549.1.1.11 as an OID for SHA256,
which is used in the default certificates supplied with gnupg2.  This is in
addition to 2.16.840.1.101.3.4.2.1, which 1.2.3 also recognized.

+++ This bug was initially created as a clone of Bug #435320 +++

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!

-- Additional comment from rdieter.edu on 2008-02-29 21:07 EST --
Sure, np.  I'll double-check all the other minimal requirements while I'm at it...

-- Additional comment from mattdm on 2008-02-29 21:26 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.

-- Additional comment from rdieter.edu on 2008-02-29 21:29 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?

-- Additional comment from mattdm on 2008-02-29 21:36 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.

-- Additional comment from rdieter.edu on 2008-02-29 21:44 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.

-- Additional comment from mattdm on 2008-02-29 22:06 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. :)

-- Additional comment from rdieter.edu on 2008-02-29 22:17 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.  

-- Additional comment from mattdm on 2008-02-29 23:05 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. :)

-- Additional comment from nalin on 2008-03-03 13:55 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 1 Nalin Dahyabhai 2008-03-03 19:19:49 UTC
Created attachment 296664 [details]
sample program to be built with libgcrypt

Comment 2 RHEL Program Management 2008-06-04 22:46:02 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 7 errata-xmlrpc 2009-01-20 21:43:06 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0174.html


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