Garance, On Aug 11, 2017, at 23:26 , Garance A Drosehn wrote:
> On 11 Aug 2017, at 15:47, Jan Iven wrote: > >> On 11/08/17 21:39, Garance A Drosehn wrote: >>> >>> Ah, thanks! I had guessed that it might be his PGP key that I >>> needed, but the only keyserver that my GPG Keychain application >>> searches is hkp://keys.gnupg.net , and his key did not show up >>> there. >>> >>> Hmm. Actually keys.gnupg.net *does* know about his key, but did >>> not show it to me because it lists the key as expired, and I had >>> the key-search avoid any keys which are revoked or expired. >>> [...] yes, the key has expired quite a while ago. >>> And when I run the source-rpm through rpm with that key, I still >>> see the warning "... Signature, key ID 9e590f86: NOKEY". Note that if I hadn't signed the SRPM at all, your rpm command would have silently installed the source package, without any warning. Would you prefer that? >>> It often takes me multiple times to do anything with PGP keys, so >>> maybe I'm still doing something wrong here? Especially since I'm >>> getting the message "Oops: keyid_from_fingerprint: no pubkey" . >> >> >> I think you'll need to download the ASCII version of his public >> key, and provide the file to "rpmkeys --import". Careful: That will instruct rpm/yum to trust my key forever and for packages from any repository. I wouldn't recommend that... > That is basically what I did, except I did it through the program > that https://gpgtools.org provides for macOS, called GPG keychain. > That has worked for other keys that I've added to my pubring. > > Also, once I told GPG keychain to show me keys which have expired, then > I could find the same key through hkp://keys.gnupg.net. And after > updating the key from hkp://keys.gnupg.net , the result was the same. > >> But please note that while verifying source integrity is a good >> idea, you do not need to install the source RPM. You download >> (+verify: "rpmkeys --checksig") + recompile it, and the resulting >> binary RPMs will be not signed (unless you sign them yourself). See above. Unless you really want to trust my key for everything, I recommend importing it into a separate rpmdb used for nothing else but checking my signature. ("rpm --dbpath ..."). > I'm not looking to sign the binary RPM's (although I should learn > to do that!). I just want to be sure that the source-RPM that I > downloaded really is the one that OpenAFS.org has released. And > that someone hasn't replaced it with a different source-RPM which > *they* signed with *their* PGP key. > > I'm not sure why, but today I got to thinking that I should be more > paranoid about that verifying the pgp key as long as someone is > taking the trouble to sign it. Good thinking, but you should reject any rpms not signed at all then. > I tried the above verify command, > and the output is: > > rpmbuild/SRPMS/openafs-1.6.21-1.el7.src.rpm: sha1 md5 OK > > But I *think* that just tells me that the RPM is the same as it > was when it was signed. But it doesn't tell me who signed it. It means the payload checksums are the same as when the SRPM was built. Which is just a bit weaker than the sha256 checksums we now provide for the tarballs. > Apologies for all the extra noise here. No, bringing this up is fine IMO. I wish more folks would think about whom they actually trust when they run "rpm --rebuild", "make" (& Co.), "pip", "easy-install", "go get" ... [...] > Also, fwiw, I'm using the source-RPM to build for RHEL7, not CentOS. That shouldn't matter. > I'm trying to generate new binary-RPM's for the new RHEL7 kernel > that Redhat released last week. And I'm having no trouble creating > those RPM's, but today I got to thinking that my first step should > be to verify the source-RPM that I start out with. Not just that the > digests are valid, but that I know who it was that signed the rpm. Well, that was me, and the signature on the package is my current best effort to prove it. While the key is well past the expiration date set when I created it, rpm doesn't care, and a simple google search for the public key file yields several hundred hits across the globe, which is mostly due to the fact that it was distributed with Scientific Linux releases up to SL5 (admittedly, many no longer work since SL5 is EOL and was archived a few months ago). Ideally, I would sign the srpms with the same private key used for the binary rpms we provide. Alas, I don't have access to that key (which on the other hand is proof that key secrecy is being taken seriously in the project). Ultimately, what counts is the git tag for a release signed by an AFS gatekeeper/guardian (thus, NOT me). The src/doc tarballs are programatically derived from a checkout of that tag, and the srpm is programatically derived from just those (with the sole exception of the CellServDB). Which means there is a reasonably strong chain of trust all the way down from git.openafs.org to the srpm. It's just not trivial to verify. But it does exist, and it's most likely that breaches would be noticed. > (FWIW, at this point I have generated the new binary RPM's, and > they are working fine with the new RHEL7 kernel 3.10.0-693) Thanks for the success report. We don't receive all that many of those these days. In fact we haven't received any for a ling time. > Thanks again for the replies. Yes, thanks to anyone who chimed in. -- Stephan _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
