On Mon, Dec 03, 2012 at 08:33:25PM +0100, Stanislav Brabec wrote:

Stanislav Brabec wrote:

...

I just implemented signature verification for all packages, that already contained signature and/or trusted keyring. But I did not verify, that signature submitted by packagers is the signature of the real author.

Just a hint for people, who got one of these request:

If you want to build package for older SUSE versions and don't want to link or aggregate gpg-offline to your devel projects nor use ugly prjconf trick, feel free to add %if statements to your spec file.

Example:

Source2. %{name}.keyring +%if 0%{?suse_version} > 1220 BuildRequires: gpg-offline +%endif

If we accept the verification is applied for Factory packages only, maybe coolo can call it from factory-auto scripts? Then we don't need to pollute BuildRequires and %prep - the downside is it won't work on devel projects, or in plain rpm as your approach. CCying coolo: what do you thing? Regards Michal Vyskocil

...

%prep +%if 0%{?suse_version} > 1220 %gpg_verify %{S:1} +%endif %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

Quoting Stephan Kulow :

On 04.12.2012 09:26, Michal Vyskocil wrote:

This actually sounds like to be put in the source validator or a similiar source service that runs on checkin. And that I can then call from factory-auto

I agree that ugly %suse version %preps are not worth the extra felt security - especially as we do no checks about the keyring whatsoever.

I do indeed prefer the 'automatic' approach as opposed to having all this info in the .spec files (similar to checkin services or brp-checks). 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... and ANY change on the .keyring file should trigger an immediate warning for the review team, to give an extra heads up that this might be an attempt to alter the security model. Or, as the first suggestion was, have the .keyring in a collective package in Factory and 'allow' the .keyring to be used as an extension in devel projects / non-factory packages. Not too easy to ensure nothing goes wrong at no place... Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Andreas Jaeger wrote:

Stanislav,

Once all of this is cleaned up, please document exactly what needs to be done in a new wiki page as part of the packaging guidelines.

I do like this but this needs proper documentation,

Here is the link to the actual state: https://build.opensuse.org/package/view_file?expand=1&file=gpg-offline.PACKAGING.HOWTO&package=gpg-offline&project=Base%3ASystem There is also a man page, but this one documents expected packaging use. -- 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

Quoting Michal Vyskocil :

I would say having .keyring with a package, proposed by Ludwig, is better solution. It increases a flexibility and reduce the need of the special package for submission.

Security vs comfort/flexibility... as usual :)

I agree that a manual review is not the coolest approach ever, but that

1.) Can't be easily workarounded 2.) Needs to be done only for the first time - all other changes will be rare

But it is a good idea to have something in a webui showing big-red-something during .keyring file change.

This part I consider really important for 'us' reviewers... I'm afraid it's too easy to be missed otherwise.. if we add a 'big red warning' we can also link to a 'review howto'.. as we will likely not to it daily :) Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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 sub 1024g/0A9EB17D 2004-06-29 vsftpd.keyring is a valid armored GPG keyring and the human readable description corresponds to its contents. -- 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

Dominique Leuenberger a.k.a DimStar wrote:

Quoting Stanislav Brabec :

...

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 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 " not changed gpg: Total number processed: 1 gpg: unchanged: 1 pub 1024D/3C0E751C 2004-06-29 uid Chris Evans 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

Dominique Leuenberger a.k.a DimStar wrote:

Quoting Stanislav Brabec :

...

...

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?

Well, as we don't have anything 'yet', it's the best we can do

In case of my ~50 submit requests, we already have a signature, in case of few packages, also a keyring in a different format. For example, we have many existing signatures created by BB5F58CC Netfilter Core Team in the Factory. Well, it is not evident, that BB5F58CC private key is really owned only by Netfilter Core Team members, but those signatures made over time are at least a strong indication that the signing key is correct one. Maybe there is even somebody, who even has BB5F58CC in the web of trust.

This is, imho, a mandatory check for a new tarball to be checked in: if the key is revoked, a new tarball is very likely to come from a compromised source if it validates against said .keyring. Hence, it must be blocked at checkin. I agree though, tarballs signed before the revoking act must remain building.

Yes, it is true. The check should be mandatory. But there may be problematic situations: - Imagine you prepared a security update for the version created 5 years ago. Just a patch is added. Warning is OK, bug check-in process has to be smart enough to not reject unchanged tarball automatically. Tarball was not changed, it could have been signed years ago before compromising the signing key. GPG provides no guarantee for the date stamp, so we have to use a different channel to guess the real signing time. (Yes, there can be GPG based guaranteed date stamping engine, but I am not aware of any such public and free service.) - Some projects didn't upload public part of signing key to the key server (e. g. python-dnspython). What now? - Much more complicated situation may happen, if the packager updates package with a delay, the tarball was signed, but the signing key was revoked before the submit request. In such situation there is no evidence, what exactly happened.

...

vsftpd.keyring is a valid armored GPG keyring and the human readable description corresponds to its contents.

This part is good... but it does not guarantee to be the actual 'upstream' key...

The difficulty is, of course, only at the beginning, to get this bootstrapped.. once the .keyring is in, any change to it has to be considered 'questionable'.

There are some possible exceptions: - Subkey was added or removed - UID was added, removed or revoked - Key expiration was extended -- 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

Michal Vyskocil wrote:

On Tue, Dec 04, 2012 at 09:53:10AM +0100, Stephan Kulow wrote:

...

This actually sounds like to be put in the source validator or a similiar source service that runs on checkin. And that I can then call from factory-auto

That's probably a good idea @sbrabec, can I ask for this change?

Yes. gpg-offline tool is ready for both online check and offline check. It should be clean, how it should work. Should be automatic check based on file names? %{name}.keyring, *.asc *.gpg *.sig However it will not make review team work easier: Reviewer still has to review any changes in the keyring. -- 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

Jan Engelhardt wrote:

On Monday 2012-12-03 20:33, Stanislav Brabec wrote:

...

Example:

Source2. %{name}.keyring +%if 0%{?suse_version} > 1220 BuildRequires: gpg-offline +%endif

... %prep +%if 0%{?suse_version} > 1220 %gpg_verify %{S:1} +%endif %setup -q

%prep %if 0%{?gpg_verify:1} %gpg_verify %{S:whateverthesigfile} %endif ...

I already updated it in the documentation: https://build.opensuse.org/package/view_file?expand=1&file=gpg-offline.PACKAGING.HOWTO&package=gpg-offline&project=Base%3ASystem Section "Use %if in spec file"

And I prefer >= ("starting from") over > ("newer than"), since - remember - 1221 can come after 1220.

Current Factory contains: %suse_version 1230 Use of >1220 would work for 1221, >=1230 would not. But both will work equally. We have 1230, so we will probably not downgrade to 1221. -- 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

Hello, Am Dienstag, 4. Dezember 2012 schrieb Jan Engelhardt:

%prep %if 0%{?gpg_verify:1} %gpg_verify %{S:whateverthesigfile} %endif

You can even use a one-liner ;-) %prep %{?gpg_verify: %gpg_verify %{S:whatevernumber} } (tested with rpm --eval, not in a real package) Bonus points if gpg-offline gets added to the set of packages installed in every build environment - this would avoid the additional version- dependent BuildRequires. Regards, Christian Boltz --

...

[Website] Es ich wichtig, daß ich meinem Kunden sagen kann "Ja. Der kommt nicht rein. Hatte ich ja angekündigt. Hier, Gesprächsprotoll vom 19.3.2003, Zitat: 'Auf die paar Leutchen ohne Windows können wir verzichten'. Zitat Ende." LOL Und wie reagieren die darauf? Nimm dir einen Spiegel und beiss in eine Zitrone. :-)))) [> Achim Lehmkuhl und Ratti in suse-linux]

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org