[OpenAFS] OpenAFS release 1.6.21 available

[Stephan Wiesand]

Garance,

On Aug 11, 2017, at 23:26 , Garance A Drosehn wrote:

> On 11 Aug 2017, at 15:47, Jan Iven wrote:
>=20
>> On 11/08/17 21:39, Garance A Drosehn wrote:
>>>=20
>>> 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.
>>>=20
>>> 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" .
>>=20
>>=20
>> 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.
>=20
> 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.
>=20
>> 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.
>=20
> 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:
>=20
>   rpmbuild/SRPMS/openafs-1.6.21-1.el7.src.rpm: sha1 md5 OK
>=20
> 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