On Wed, Jul 10, 2013 at 03:01:07PM -0700, Brian C. Lane wrote:

On Mon, Jul 08, 2013 at 11:15:05PM +0200, Till Maas wrote:

...

Hi,

upstream of pam_mount pointed me to OpenSUSE's gpg-offline RPM macros at https://build.opensuse.org/package/show/Base:System/gpg-offline

They allow to use a keyring and detached signature as additional source in SPECs to get both verified. Since gpg-offline's upstream is willing to create a proper release to allow easy packaging for Fedora, I wonder if I will find any obstacles when I package it. The packaging guidelines allow packaging RPM macros, therefore this should be fine.

Also I am interested whether there are better options available.

In parted we have a signed upstream package and a detached signature. In the pkg git we have the signer's public key and in %prep it runs gpg.

Source0: ftp://ftp.gnu.org/gnu/%{name}/%{name}-%{version}.tar.xz Source1: ftp://ftp.gnu.org/gnu/%{name}/%{name}-%{version}.tar.xz.sig Source2: pubkey.jim.meyering

gpg --import %{SOURCE2} gpg --verify %{SOURCE1} %{SOURCE0}

What does gpg-offline add to this?

I did not yet read it, but your code has several flaws:

- It modifies the users default GPG keyring, which might be considered rude (if it is not run on Koji or in mock) - It does not ensure that the signature is actually from the key that is provided as Source2 - It either does not work if the key is not trusted or allows signatures from untrusted keys, because the provided key is not especially marked as trusted

I hope that gpg-offline does not have these flaws but since addressing this needs a little mit more code, a macro seems to be the right way to do this for me.

Regards Till

On Tue, Oct 08, 2013 at 10:22:57AM -0400, Konstantin Ryabitsev wrote:

gpgv --homedir /tmp --keyring %{SOURCE2} --status-fd=1 %{SOURCE1} %{SOURCE0} | grep -q '^[GNUPG:] GOODSIG'

<snip>

That one-liner is pretty much all that's required for valid gpg verification.

Hope this helps.

Yes it does. Thanks!

-jf

On Fri, Oct 11, 2013 at 7:02 AM, Björn Persson bjorn@xn--rombobjrn-67a.se wrote:

Konstantin Ryabitsev wrote:

...

gpg --verify (and gpgv) will return 0 even if the key is revoked or expired, so you can't really rely on exit code alone. The following is the right approach:

gpgv --homedir /tmp --keyring %{SOURCE2} --status-fd=1 %{SOURCE1} %{SOURCE0} | grep -q '^[GNUPG:] GOODSIG'

Will that check start to fail when the key expires? Do we want packages to start failing to build just because a certain date has passed?

Or does the check fail only if the key had already expired when the signature was made?

Looks like gpg verify doesn't take that into consideration. E.g., here's a signature check for a tarball signed a year ago with a key that expired 6 months later:

# gpgv --homedir=/tmp --keyring=/var/lib/kup/pgp/mcgrof.gpg --status-fd=1 /pub/pub/linux/kernel/projects /backports/2012/12/19/compat-drivers-2012-12-19-u.tar.sign compat-drivers-2012-12-19-u.tar gpgv: Signature made Thu 20 Dec 2012 04:11:59 AM UTC using RSA key ID 0A286BA2 [GNUPG:] KEYEXPIRED 1375474838 [GNUPG:] SIGEXPIRED [GNUPG:] KEYEXPIRED 1375474838 [GNUPG:] SIGEXPIRED [GNUPG:] SIG_ID CnG8MpelL0KA+rXPtnnpr8hYBKQ 2012-12-20 1355976719 [GNUPG:] KEYEXPIRED 1375474838 [GNUPG:] SIGEXPIRED [GNUPG:] EXPKEYSIG 05C1321D0A286BA2 Luis R. Rodriguez mcgrof@do-not-panic.com gpgv: Good signature from "Luis R. Rodriguez mcgrof@do-not-panic.com" gpgv: aka "Luis R. Rodriguez mcgrof@gmail.com" gpgv: aka "Luis R. Rodriguez mcgrof@frijolero.org" gpgv: aka "Luis R. Rodriguez mcgrof@qca.qualcomm.com" gpgv: aka "Luis R. Rodriguez mcgrof@winlab.rutgers.edu" gpgv: aka "[invalid image]" [GNUPG:] VALIDSIG 11D2BF2E7B1F71AE7C3ED8D605C1321D0A286BA2 2012-12-20 1355976719 0 4 0 1 2 00 11D2BF2E7B1F71AE7C3ED8D605C1321D0A286BA2

Gpg doesn't mark it with "GOODSIG", even though KEYEXPIRED timestamp (Aug, 2013) is much larger than the one in SIG_ID (Dec, 2012) -- meaning that at the time of signing the key was valid. So, yes, if gpg verify is used to check signatures, a package will start failing once the key used to sign the package is expired. Which is not necessarily a bad thing -- an FTBFS bug would be a perfectly fine way of notifying someone that they need to review the pubkey used to verify their packages.

(This, of course, can be worked around by checking for KEYEXPIRED and then doing some basic math, but of course, that would dramatically complicate the handy one-liner.)

Regards,

On Tue, Oct 08, 2013 at 10:22:57AM -0400, Konstantin Ryabitsev wrote:

On Wed, Jul 10, 2013 at 6:01 PM, Brian C. Lane bcl@redhat.com wrote:

...

In parted we have a signed upstream package and a detached signature. In the pkg git we have the signer's public key and in %prep it runs gpg.

Source0: ftp://ftp.gnu.org/gnu/%{name}/%{name}-%{version}.tar.xz Source1: ftp://ftp.gnu.org/gnu/%{name}/%{name}-%{version}.tar.xz.sig Source2: pubkey.jim.meyering

gpg --import %{SOURCE2} gpg --verify %{SOURCE1} %{SOURCE0}

What does gpg-offline add to this?

Sorry to jump on a very old thread, but I just saw this and want to add the following comments: gpg --verify (and gpgv) will return 0 even if the key is revoked or expired, so you can't really rely on exit code alone. The following is the right approach:

gpgv --homedir /tmp --keyring %{SOURCE2} --status-fd=1 %{SOURCE1} %{SOURCE0} | grep -q '^[GNUPG:] GOODSIG'

Does this allow anyone on the same machine with access to /tmp to confuse/take over gpgv?

Zbyszek