rpm --nosignature reversed meaning

Jeffrey Johnson n3npq at me.com
Tue Aug 30 11:56:43 CEST 2016

> On Aug 30, 2016, at 5:17 AM, Tomasz Pala <gotar at polanet.pl> wrote:
> On Tue, Aug 30, 2016 at 03:24:02 -0400, Jeffrey Johnson wrote:
>>> ~: strace -erecvfrom rpm --nosignature -qp keepassx-2.0.2-2.x86_64.rpm
>>> recvfrom(12, "\25\24\201\200\0\1\0\5\0\0\0\0\2ha\4pool\16sks-keyserv"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("")}, [16]) = 124
>>> recvfrom(12, "\"\27\201\200\0\1\0\5\0\0\0\0\2ha\4pool\16sks-keyserv"..., 65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("")}, [16]) = 184
>>> keepassx-2.0.2-2.x86_64
>>> +++ exited with 0 +++
>> The 2 line snippet looks like a pubkey lookup: undefine %_hkp_keyserver to disable the lookup
> Thanks, that did the trick - it interferes with my network-restricted
> environment. I need all the verification to happen locally, and preferably
> FAIL BADLY when not possible (i.e. no networked key-server available and no GPG pubkey imported).

The 2 line snippet is DNS to port 53 … disabling hkp:// is an entirely different
functionality than disabling signature verification.

> Is there any macro/option that prevents me from installing any unsigned/unverified package?

The question as asked cannot be answered: all (RPM5 built) packages are signed
and (w/o —nosignatures) the signature will be verified.

> Warning is not enough, I want to be totally sure the verification was done and succeeded.

All BAD signatures will stop RPM (unless —no signatures has been used).

>> Use -vv to see signature verification (which is likely disabled w ???nosignature).
>> AFAIK, PLD has also reenabled the ???nosignature in ???system.h??? ??? the
>> code will be removed in rpm-5.4.18 (and rpm-5.4.17 was distributed with MANDATORY signatures).
>> I will send that patch to PLD if you choose to continue supporting a ???nosignature option.
> Apparently noone here uses this...
> http://ftp.th.pld-linux.org/dists/th/PLD-3.0-Th-GPG-key.asc
> ~: rpm -qp --nosignature  keepassx-2.0.2-2.x86_64.rpm	(reversed meaning in query mode bug)
> error: keepassx-2.0.2-2.x86_64.rpm: Header V4 DSA signature: BAD, key ID e4f1bc2d
> error: reading keepassx-2.0.2-2.x86_64.rpm manifest, non-printable characters found

Um, I believe I’ve used that pubkey … see if there isn’t a report from
spring 2015 on pld-devel … the issue was that the RSA fingerprint was
fixed and so that pubkey had to be reimported. I’ve forgotten …

What version of rpm is this?

> ~: rpm -K keepassx-2.0.2-2.x86_64.rpm             
> keepassx-2.0.2-2.x86_64.rpm: (SHA1) DSA sha1 md5 NOT_OK

FWIW, -K —checksig  is mostly historical remnant as well: rpm always verifies *.rpm
header-only signatures. The option remains solely because I don’t feel like
explaining why -K isn’t necessary ...

> ~: rpm -qa gpg-pubkey\*
> gpg-pubkey-e4f1bc2d-47b351f0
> ~: diff PLD-3.0-Th-GPG-key.asc /etc/pki/rpm-gpg/PLD-3.0-Th-GPG-key.asc 

Try removing and reimporting.

> (BTW this key is not automatically imported to rpm database).

No pubkey is automatically imported by RPM, particularly those retrieved from hkp://
or externally generated signatures.

Meanwhile, all imported pubkeys (including for the non-repudiable pubkey
present in all RPM5 built *.rpm packages) are indexed in /var/lib/rpm/pubkeys
for retrieval. If the keyed goes off the rails

The flaw with the PLD-Th-GPG-key.asc (from memory) was that RSA (but not DSA/ECDSA)
does not guarantee that the most significant bit is set, and so an assumption that bit
count == 8 * byte count fails.

There is also a 1-in-256 chance that all 8 leading bits are zero, in which case the no. of
bytes is wrong as well.

Adding the bit count properly (as specified in RFC 4880) changes the RSA pubkey fingerprint
because the bit count is part of the key material.

Anyways if you give me a URL to the pubkey and a package signed with that pubkey, I’ll
(again) sort out the details.

I can’t quite tell what to do with —nosignature because PLD <-> rpm5.org are headed
in different directions and not working with the same source code.

But I believe the PLD-Th-GPG issue was discussed in spring 2015 on pld-devel.

73 de Jeff

> -- 
> Tomasz Pala <gotar at pld-linux.org>
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

More information about the pld-devel-en mailing list