Bug 624585 - Lost ability to sign rpms
Lost ability to sign rpms
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F14Target
  Show dependency treegraph
 
Reported: 2010-08-17 01:25 EDT by Nicolas Mailhot
Modified: 2012-03-31 02:43 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-31 02:43:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nicolas Mailhot 2010-08-17 01:25:37 EDT
Description of problem:

With the recent gnupg churn, applying F14 updates, the system upgrades to a state where rpm --resign does not work anymore

Version-Release number of selected component (if applicable):
gnupg2-2.0.16-2.fc14.x86_64
gnupg2-smime-2.0.16-2.fc14.x86_64
rpm-4.8.1-5.fc14.x86_64
rpm-build-4.8.1-5.fc14.x86_64
rpmdevtools-7.9-1.fc14.noarch
rpmfusion-free-release-14-0.2.noarch
rpmfusion-nonfree-release-14-0.2.noarch
rpm-libs-4.8.1-5.fc14.x86_64
rpmlint-0.98-2.fc14.noarch
rpm-python-4.8.1-5.fc14.x86_64
Comment 1 Tomas Mraz 2010-08-17 03:43:27 EDT
Hopefully this will be fixed with the switch back to the gnupg-1 for the gpg binary.
Comment 2 Tomas Mraz 2010-08-17 03:47:54 EDT
Ah, actually the gnupg2 package you have already does not contain the compat gpg symlink. Please install the gnupg package.
Comment 3 Nicolas Mailhot 2010-08-17 03:56:43 EDT
If rpm needs this package to work it should require it

Have gpg users been notified they needed to change their package requires?
Comment 4 Tomas Mraz 2010-08-17 04:11:36 EDT
They should require the gpg binary and not the package. There was no change in requires when the switch from gnupg to gnupg2 was done so it should not be needed in the reverse direction either.
Comment 5 Tomas Mraz 2010-08-17 04:13:27 EDT
I also suppose that rpm does not require gpg explicitly to not bloat the minimum install for optional functionality as I do not think the --resign is used on most installs. Perhaps a special subpackage for rpm should be added that would pull the gpg requirement?
Comment 6 Nicolas Mailhot 2010-08-17 04:48:50 EDT
(In reply to comment #4)
> They should require the gpg binary and not the package.

Except yum people hate file requires and have spent quite a lot of time asking people to kill them in their packages. So it is not safe to assume gpg-using packages do not require it through a package name
Comment 7 Panu Matilainen 2010-08-17 05:17:36 EDT
(In reply to comment #6)
> (In reply to comment #4)
> > They should require the gpg binary and not the package.
> 
> Except yum people hate file requires and have spent quite a lot of time asking
> people to kill them in their packages. So it is not safe to assume gpg-using
> packages do not require it through a package name

What the yum people hate is file requires outside those included in primary data as they require downloading the big otherwise unnecessary filelists data. Stuff in /usr/bin is included in the primary data which is always downloaded so it doesn't make much of a difference whether binary or package name is required.

Back to the actual issue... missing gpg dependency goes as far back in history that I can easily check for (RHL 7.0). Funny how long these things can stay lurking without apparently anybody noticing.

As it is, signing support can't be meaningfully split into a separate sub-package... so I guess I'll just have rpm require /usr/bin/gpg for now.
Comment 8 Tomas Mraz 2010-08-17 06:03:07 EDT
I meant a "virtual" or empty subpackage, that would just contain the requires and perhaps some documentation. Of course the signing support in rpm would have to fail gracefully preferably with a message to install the /usr/bin/gpg for it to work.

Having the base rpm package require gpg binary is really a bloat for a minimal installs.

Or if the require would be on rpm-build, it would be OK I think.
Comment 9 Rex Dieter 2010-08-17 07:50:36 EDT
Fwiw, gnupg2-2.0.16-2.fc14.x86_64 isn't in f14 updates (or updates-testing) yet, pending readiness of existing update,
https://admin.fedoraproject.org/updates/F14/FEDORA-2010-12595

(Concern like those described here is one reason why I've asked folks involved to wait for the aforementioned one to go stable before issuing any updates re-instating gnupg v1).
Comment 10 Panu Matilainen 2010-08-18 04:24:48 EDT
(In reply to comment #8)
> I meant a "virtual" or empty subpackage, that would just contain the requires
> and perhaps some documentation. Of course the signing support in rpm would have
> to fail gracefully preferably with a message to install the /usr/bin/gpg for it
> to work.

That's what I meant with "not doable as is". Actually rpm does provide a semi-meaningful error message on missing gpg... but only when run in verbose mode:
[pmatilai@dhcp102 ~]$ rpm -v --resign /tmp/gnupg-1.4.10-2.fc13.x86_64.rpm 
Enter pass phrase: 
error: Could not exec gpg: No such file or directory
Pass phrase check failed

In normal verbosity level, rpm closes the stderr of the child forked for running gpg, effectively hiding the error message. No idea whether it was to avoid message spewage from some old version of gpg, with current versions it doesn't seem to make any difference on the output in non-error case. So might as well make the default case show errors too and improve the message while at it.

> 
> Having the base rpm package require gpg binary is really a bloat for a minimal
> installs.
> 
> Or if the require would be on rpm-build, it would be OK I think.

Well, rpm-build doesn't require gpg any more than rpm itself does - both only need it if you're doing signing on the box. And OTOH creating a sub-package for nothing but a single dependency seems a bit silly too.

A related issue is that AFAIK there's no particular reason for rpm to require gnupg-1.4, it could just as well use gnupg2 and that gets dragged in by yum already, so its likely to be present on even minimal installs already (unless you count mock buildroots)
Comment 11 Tomas Mraz 2010-08-18 04:42:38 EDT
OK, so perhaps it could try to exec /usr/bin/gpg and if not found /usr/bin/gpg2 then? Or the other way around?
Comment 12 Panu Matilainen 2012-03-31 02:43:27 EDT
Fedora 14 is EOL, in Fedora >= 15 rpmsign the packaging is a bit different and gpg is required where necessary.

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