4:15 p.m.
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.
Regards
Till
4:42 p.m.
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.
I would be interested in using whatever you come up with in order to
verify libguestfs sources, so let me know if there's something to
test.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
4:59 p.m.
On Mon, 8 Jul 2013 23:15:05 +0200
Till Maas <opensource(a)till.name> 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.
Interesting. I'd add that you might want to ping the FPC to get
guidelines for this added once it's available and update packaging docs
to tell people how to use it. It seems pretty simple though...
kevin
5:01 p.m.
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?
--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
11:46 a.m.
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
9:22 a.m.
On Wed, Jul 10, 2013 at 6:01 PM, Brian C. Lane <bcl(a)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'
The pubkey (source2) format has to be an actual keyring (gpg --export
keyid > keyring.gpg), not an ascii pubkey block.
That one-liner is pretty much all that's required for valid gpg verification.
Hope this helps.
Best,
--
Konstantin Ryabitsev
LinuxFoundation.org
Montréal, Québec
1:56 a.m.
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
6:02 a.m.
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?
--
Björn Persson
Sent from my computer.
8:55 a.m.
On Fri, Oct 11, 2013 at 7:02 AM, Björn Persson
<bjorn(a)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(a)do-not-panic.com>
gpgv: Good signature from "Luis R. Rodriguez <mcgrof(a)do-not-panic.com>"
gpgv: aka "Luis R. Rodriguez <mcgrof(a)gmail.com>"
gpgv: aka "Luis R. Rodriguez <mcgrof(a)frijolero.org>"
gpgv: aka "Luis R. Rodriguez <mcgrof(a)qca.qualcomm.com>"
gpgv: aka "Luis R. Rodriguez <mcgrof(a)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,
--
Konstantin Ryabitsev
LinuxFoundation.org
Montréal, Québec
9:02 a.m.
On Fri, Oct 11, 2013 at 9:55 AM, Konstantin Ryabitsev
<icon(a)fedoraproject.org> wrote:
> 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.
PS: And, FYI, for a very good reason -- it is very simple for an
attacker to change the date on their system before signing a tarball,
to make it look like the signature was made while the key was still
valid and thus satisfy the checks.
--
Konstantin Ryabitsev
LinuxFoundation.org
Montréal, Québec
2:32 p.m.
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(a)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
11:19 p.m.
On Fri, Oct 11, 2013 at 3:32 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> 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?
That's just an example -- gpgv doesn't appear to have the
"--no-default-keyring", so you should point --homedir to any location
where there isn't a pubring.gpg file (or you can mktemp -d one, to be
extra safe). In kup, we create a safe tempdir as part of the overall
operation and pass that as the homedir.
Since we're talking about this in the rpm spec context, "--homedir
%{buildroot}" would do the trick, since it's destroyed before each rpm
build.
Regards,
--
Konstantin Ryabitsev
LinuxFoundation.org
Montréal, Québec
9:59 a.m.
----- Original Message -----
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.
Hi Till,
Any news on packaging this? I'm interested to see what we can do with it.
Thanks.
--
Josh Bressers / Red Hat Product Security Team
12:12 p.m.
Hi Josh,
On Thu, Oct 03, 2013 at 10:59:24AM -0400, Josh Bressers wrote:
> 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.
>
Hi Till,
Any news on packaging this? I'm interested to see what we can do with it.
no, sorry, I did not get any further, yet.
Regards
Till
3846
days inactive
3942
days old
13 comments
9 participants
participants (9)
-
Björn Persson -
Brian C. Lane -
Jan-Frode Myklebust -
Josh Bressers -
Kevin Fenzi -
Konstantin Ryabitsev -
Richard W.M. Jones -
Till Maas -
Zbigniew Jędrzejewski-Szmek