[opensuse-factory] build time verification of GPG signatures
Hi. As discussed in past[1], Factory now has gpg-offline package, which is a wrapper on top of gnupg, which allows simple build time offline verification of GPG signatures. It makes possible to verify tarballs in the build time. The use of gpg-offline in spec files is really simple: https://build.opensuse.org/package/view_file?expand=1&file=gpg-offline.PACKAGING.HOWTO&package=gpg-offline&project=Base%3ASystem The package also contains a man page. The first time step is very security-sensitive: You define your package keyring - a list of trusted keys, that can be used by the upstream to sign the source of your package. Check carefully that you are not adding a malicious keys there. Be paranoid! The gpg_verify tool is able to detect hacked source on the upstream servers (and such bad thing really already happened[2]!), but it is not able to detect maliciously uploaded false signature on the key servers. If the upstream author is in your web of trust, you are on a safe side. But if he/she is not in your web of trust, you have to use alternative ways to trust the key: - If you can mail to the author and verify the key, it is very probably an authorized signature. - If the signing key is the same as the one used a year ago, it is probably an authorized signature. - If the signing key was used in mailing list many times to sign developer mails, or at least it was announced there, it is probably an authorized signature. - If you can find the public key or footprint on more servers on different hostings, it is probably an authorized signature. 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. Feedback, feature requests and bug reports are welcome. [1] http://lists.opensuse.org/opensuse-packaging/2012-09/msg00029.html [2] http://scarybeastsecurity.blogspot.cz/2011/07/alert-vsftpd-download-backdoor... There is still one FIXME: If anybody knows, how to use trust model "all keys in the local keyring are trusted" without "gpg: WARNING: Using untrusted key!", please advise. -- 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
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 ... %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
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
On 04.12.2012 09:26, Michal Vyskocil wrote:
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?
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. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Stephan Kulow <coolo@suse.de>:
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
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, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- 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
On Tue, Dec 04, 2012 at 10:12:07AM +0100, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Stephan Kulow <coolo@suse.de>:
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.
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. 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. Regards Michal Vyskocil
Quoting Michal Vyskocil <mvyskocil@suse.cz>:
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
On Tue, Dec 04, 2012 at 11:32:22AM +0100, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Michal Vyskocil <mvyskocil@suse.cz>:
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 would not say having one central keystore is more secure - you would need to trust package maintainers and now you have to trust the review team, which is a trustful group, isn't it? ;-)
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 :)
I will sumit a feature for OBS, but I'd like to wait till all rough points will be clear. Atm, there are * move it to source checking * central keystore Anyway a link to documentation is a great idea, I'll add it then. Regards Michal Vyskocil
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 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
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. 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 :) 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:
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
Quoting Stanislav Brabec <sbrabec@suse.cz>:
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
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.
This is not valid just now: there is no .keyring ring in Factory for years... An update of a .keyring file be legit later on, but the 'validity' is not easy to establish, without direct contact with upstream. So another task to be performed by the reviewers (initially, this should also happen for each new .keyring file!)
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
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.
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'. 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:
Quoting Stanislav Brabec <sbrabec@suse.cz>:
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 <coreteam@netfilter.org> 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
On Tue, Dec 04, 2012 at 09:53:10AM +0100, Stephan Kulow wrote:
On 04.12.2012 09:26, Michal Vyskocil wrote:
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?
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?
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've emailed the HOWTO for a review team how to check keyrings. Therefor at least for a factory, all .keyring files will be reviewed by us. I'm afraid there is no easy way how to deal with it, unless someone else will review it manually. Regards Michal Vyskocil
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
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 ... And I prefer >= ("starting from") over > ("newer than"), since - remember - 1221 can come after 1220. -- 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
On Tuesday 2012-12-04 16:06, Stanislav Brabec wrote:
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.
gpg-offline is available starting 1230, not 1221 ;) -- 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
participants (7)
-
Andreas Jaeger -
Christian Boltz -
Dominique Leuenberger a.k.a DimStar -
Jan Engelhardt -
Michal Vyskocil -
Stanislav Brabec -
Stephan Kulow