This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 209889 - rpmlint gpg-pubkey give weird results
rpmlint gpg-pubkey give weird results
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: rpmlint (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
:
: 209869 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-07 11:00 EDT by Ralf Corsepius
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 0.78-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-15 10:04:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Fix false assumptions about some tags' existence (1.49 KB, patch)
2006-10-09 13:37 EDT, Ville Skyttä
no flags Details | Diff
traceback at the end of "rpmlint -a" (115.98 KB, application/octet-stream)
2006-10-09 23:57 EDT, Ralf Corsepius
no flags Details

  None (edit)
Description Ralf Corsepius 2006-10-07 11:00:51 EDT
Description of problem:

Running
rpmling gpg-pubkey
gives bogus results and ends up with a traceback. 
It apparently is not handling this special case correctly.

Version-Release number of selected component (if applicable):
rpmlint-0.78-1.fc5

How reproducible:
# rpmlint gpg-pubkey
W: gpg-pubkey summary-not-capitalized gpg(Livna.org rpms <rpm-key@livna.org>)
W: gpg-pubkey non-standard-group Public Keys
E: gpg-pubkey no-changelogname-tag
W: gpg-pubkey invalid-license pubkey
W: gpg-pubkey no-url-tag
Traceback (most recent call last):
  File "/usr/share/rpmlint/rpmlint.py", line 268, in ?
    main()
  File "/usr/share/rpmlint/rpmlint.py", line 92, in main
    runChecks(pkg)
  File "/usr/share/rpmlint/rpmlint.py", line 149, in runChecks
    c.check(pkg)
  File "/usr/share/rpmlint/BinariesCheck.py", line 140, in check
    res=srcname_regex.search(pkg[rpm.RPMTAG_SOURCERPM])
TypeError: expected string or buffer
Comment 1 Ville Skyttä 2006-10-09 13:32:23 EDT
*** Bug 209869 has been marked as a duplicate of this bug. ***
Comment 2 Ville Skyttä 2006-10-09 13:37:50 EDT
Created attachment 138057 [details]
Fix false assumptions about some tags' existence

This happens because rpmlint incorrectly assumes that everything has a source
rpm - gpg-pubkeys obviously don't - and proceeds to blindly try to access the
SRPM name as a string.	Fixing this uncovers other similar incorrect
assumptions, but I think the attached patch (upstream site is inaccessible so
I'll attach it here) catches them.

Another thing that should probably be done would be to filter everything about
gpg-pubkeys, by adding 'addFilter("gpg-pubkey")' to /usr/share/rpmlint/config. 
Opinions?
Comment 3 Ralf Corsepius 2006-10-09 13:42:00 EDT
(In reply to comment #1)
> *** Bug 209869 has been marked as a duplicate of this bug. ***

Why? 209869 was meant to be about the traceback, while this one was meant to be
on the "meaningfulness" of these warnings:

W: gpg-pubkey summary-not-capitalized gpg(Livna.org rpms <rpm-key@livna.org>)
W: gpg-pubkey non-standard-group Public Keys
E: gpg-pubkey no-changelogname-tag
W: gpg-pubkey invalid-license pubkey
W: gpg-pubkey no-url-tag

None of them is useful nor valid.

(In reply to comment #3)
This, to me is PR 209869
Comment 4 Ville Skyttä 2006-10-09 13:48:11 EDT
Both the meaninglessness and the backtrace were reported in this bug.  Bug 
209869 contains only the backtrace, but no reproducer.  Therefore I prefer to 
track both issues here.

The patch in comment 2 is a proposed fix/workaround for the backtrace, and the 
second paragraph of comment 2 contains a suggested solution for the bogosity 
of the gpg-pubkey related messages.
Comment 5 Ralf Corsepius 2006-10-09 23:51:00 EDT
(In reply to comment #4)
> Both the meaninglessness and the backtrace were reported in this bug.  Bug 
> 209869 contains only the backtrace, but no reproducer.
Well, providing a reproducer would have required to have one - When I filed
209869, all I saw was "rpmlint -a" crashing at what had seemed to be random spots.

> The patch in comment 2 is a proposed fix/workaround for the backtrace,
AFAICT so far from testing your patch, it seems to fix the backtrace for 
"rpmlint gpg-pubkey", but for "rpmlint -a", a different traceback now occurs
(Cf. attachment).

BTW: Unsurprisingly, "rpmlint -a" now takes MUCH longer (hours!) than before,
before it bombs out ;)

> and the 
> second paragraph of comment 2 contains a suggested solution for the bogosity 
> of the gpg-pubkey related messages.
I am not sufficiently familiar with rpmlint to be able to comment on this.
Generally speaking, I'd say "filtering packages by name" should be the last resort.
Comment 6 Ralf Corsepius 2006-10-09 23:57:15 EDT
Created attachment 138111 [details]
traceback at the end of "rpmlint -a"

This traceback is from the end of running "rpmlint -a" using rpmlint-0.78-1.fc5

w/ rpmlint-nosrcrpm.patch applied on FC5/i386.
The full log is > 7MB  and > 60000 lines ;)
Comment 7 Ralf Corsepius 2006-10-10 00:01:43 EDT
rpmlint iptables(In reply to comment #6)
> Created an attachment (id=138111) [edit]
> traceback at the end of "rpmlint -a"

FYI: I can deterministically reproduce the same traceback running
"rpmlint iptables"
using rpmlint-0.78-1.fc5 w/ and w/o your patch.

=> Yet another bug, unrelated to the previous ones.

Comment 8 Ville Skyttä 2006-10-10 14:37:43 EDT
(In reply to comment #5)
> > The patch in comment 2 is a proposed fix/workaround for the backtrace,
> AFAICT so far from testing your patch, it seems to fix the backtrace for 
> "rpmlint gpg-pubkey"

Applied upstream as http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1284

> Generally speaking, I'd say "filtering packages by name" should be the last
> resort.

Ditto, but I can't come up with anything better at the moment for the 
gpg-pubkey case.

(In reply to comment #7)
> 
> FYI: I can deterministically reproduce the same traceback running
> "rpmlint iptables"
> using rpmlint-0.78-1.fc5 w/ and w/o your patch.

Reproduced, I'm looking into it.

> => Yet another bug, unrelated to the previous ones.

If you happen to come across even more, could you file separate bug reports 
about them and not add new unrelated ones here?  TIA.
Comment 9 Jeff Johnson 2006-10-10 18:52:27 EDT
Filtering by name is okay, its highly unlikely that "gpg-pubkey" will ever change.

Otherwise, "gpg-pubkeys" do not have RPMTAG_ARCH, and are unlikely to ever acquire that tag,
arch is meaningless for RFC-2240 public keys.
Comment 10 Jeff Johnson 2006-10-10 18:53:10 EDT
RFC-2440, typo.
Comment 11 Jeff Johnson 2006-10-10 19:09:21 EDT
Better still would be to teach rpmlint to actually verify the
header of gpg-pubkey packages.

Version: is the fingerprint
Release: is the creation time
Group: is "Public Keys"
%description is the ascii armor'ed pubkey

Verifying the fingerprint is most important, as rpm prior to 4.4.2 did not
calculate the fingerprint directly, but rather used a field from the certification signature.

All the above is just random rpmlint RFE ideas, skipping makes perfect sense as well.
Comment 12 Ville Skyttä 2006-10-15 10:04:24 EDT
Fixed in 0.78-2.fc*

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