Dominique Leuenberger a.k.a DimStar wrote:
Quoting Stanislav Brabec <sbrabec@suse.cz>:
Dominique Leuenberger a.k.a DimStar wrote:
For 'reviews' of the entire thing, it would be mandatory for obs webui and osc to be able to 'show/decode' the information in the .keyring...
"My" format of keyring contains the keyring list in the text form.
There is an easy automatic way to check, that it matches the armored blob contents:
~/OSC/home:sbrabec:gpg-offline-verify/vsftpd> gpg-offline --review --offline --keyring vsftpd.keyring pub 1024D/3C0E751C 2004-06-29 uid Chris Evans <chris@scary.beasts.org> sub 1024g/0A9EB17D 2004-06-29
Without verifying this against an upstream published key, it's still void information... so I do expect the first-time effort to get this in rather big.
What if attacker uploads a false key to the key server? I guess we should trust keyring residing in Factory for years, which was used for verifying all released versions over 5 years, and not blindly trust a new key from the key server, especially if it is not in my web of trust. But yes, you can verify, that the user did not revoke it: ~/OSC/home:sbrabec:gpg-offline-verify/vsftpd> LANG=C gpg-offline --review --keyring vsftpd.keyring gpg: refreshing 1 key from hkp://subkeys.pgp.net gpg: requesting key 3C0E751C from hkp server subkeys.pgp.net gpg: key 3C0E751C: "Chris Evans <chris@scary.beasts.org>" not changed gpg: Total number processed: 1 gpg: unchanged: 1 pub 1024D/3C0E751C 2004-06-29 uid Chris Evans <chris@scary.beasts.org> sub 1024g/0A9EB17D 2004-06-29 vsftpd.keyring is a valid armored GPG keyring and the human readable description corresponds to its contents. If it is revoked, it is not as easy as it looks: You do not want to start to fail on 5 years old signature only because author now revoked the key. Human review is needed. If the tarball was not changed in OBS in last 5 years, it is probably OK. If it was, one has to compare revocation time and demonstrable time of the particular release, and use brain to guess whether it could be signed by a stolen private key.
I think what I like least about it is that an entire app stack (does kde publish gpg sigs?) might end up with the same .keyring over and over... but as I don't maintain that many packages that publish gpg sigs, I think I don't really mind it :)
I wanted to introduce centralized keyring and list of authorized keys for particular package, but it was considered as a bad idea: http://lists.opensuse.org/opensuse-packaging/2012-09/msg00029.html In the current gpg-offline it is possible to package keyring separately. I was thinking about it for netfilter: Example (untested): BuildRequires: gpg-offline gpg-offline-keyring-netfilter %prep %gpg_verify -f /usr/share/gpg-offline/keyrings/netfilter.keyring %{S:1} %setup -q -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org