> On Aug 30, 2016, at 5:17 AM, Tomasz Pala <go...@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("8.8.4.4")}, [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("8.8.4.4")}, [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 <go...@pld-linux.org> > _______________________________________________ > pld-devel-en mailing list > pld-devel-en@lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en