[pkg-gnupg-maint] Bug#836554: Bug#836554: gnupg - file verification leaves agent running

Daniel Kahn Gillmor dkg at fifthhorseman.net
Sun Sep 4 14:04:54 UTC 2016


Control: severity 836554 normal

On Sat 2016-09-03 18:40:26 -0400, Bastian Blank wrote:
> Package: gnupg
> Version: 2.1.15-2
> Severity: grave

I'm unclear as to why this is Severity: grave -- i've reset the Severity
to normal, but i'm happy to have you reset the severity with an
appropriate explanation.

> A simple verification of a inlined signed file leaves the agent running.
> This makes it impossible to clean up the system properly.

"impossible" is an overstatement, right?  While i agree with you that
it's better to not have the agent left running, it can at the very least
be terminated manually (e.g. with "gpgconf --kill gpg-agent" or
"gpg-connect-agent killagent /bye").

That said, let's try to figure out what's going on and make it better:

> This is for example used by cdebootstrap.

A verification of a signature should not launch the agent at all, so i'm
not convinced this is what's happening.  With a dedicated GNUPGHOME you
can observe the presence of the agent by looking for S.gpg-agent, which
doesn't appear after file verification:

    0 dkg at alice:~$ ls -la $GNUPGHOME
    total 20
    drwx------  3 dkg  dkg   160 Sep  4 08:26 .
    drwxrwxrwt 20 root root  700 Sep  4 08:25 ..
    drwx------  2 dkg  dkg    40 Sep  4 07:54 private-keys-v1.d
    -rw-r--r--  1 dkg  dkg  3039 Sep  4 08:15 pubring.kbx
    -rw-------  1 dkg  dkg   600 Sep  4 08:25 random_seed
    -rw-r--r--  1 dkg  dkg  1006 Sep  4 08:05 test.txt.asc
    -rw-------  1 dkg  dkg  1240 Sep  4 08:26 trustdb.gpg
    -rw-r--r--  1 dkg  dkg  2861 Sep  4 08:15 trustedkeys.gpg
    0 dkg at alice:~ gpg --verify test.txt.asc 
    gpg: Signature made Sun 04 Sep 2016 07:57:48 AM EDT
    gpg:                using RSA key 24ECFF5AFF68370A
    gpg: checking the trustdb
    gpg: marginals needed: 3  completes needed: 1  trust model: pgp
    gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
    gpg: next trustdb check due at 2017-01-04
    gpg: Good signature from "Daniel Kahn Gillmor <dkg at debian.org>" [ultimate]
    0 dkg at alice:~ ls -la
    total 20
    drwx------  3 dkg  dkg   160 Sep  4 08:26 .
    drwxrwxrwt 20 root root  700 Sep  4 08:25 ..
    drwx------  2 dkg  dkg    40 Sep  4 07:54 private-keys-v1.d
    -rw-r--r--  1 dkg  dkg  3039 Sep  4 08:15 pubring.kbx
    -rw-------  1 dkg  dkg   600 Sep  4 08:26 random_seed
    -rw-r--r--  1 dkg  dkg  1006 Sep  4 08:05 test.txt.asc
    -rw-------  1 dkg  dkg  1280 Sep  4 08:26 trustdb.gpg
    -rw-r--r--  1 dkg  dkg  2861 Sep  4 08:15 trustedkeys.gpg
    0 dkg at alice:~ 

So maybe it's not file verification that's causing the agent to spawn
but some other operation?

I notice that "gpg --import < publickey.gpg" spawns the agent even
though it doesn't need to, and i've opened
https://bugs.gnupg.org/gnupg/issue2669 to try to get that addressed
upstream.

> As it is inline signed, it is not possible to use gpgv, which can't
> decode messages.

gpgv can verify inline-signed data, but does not produce output of the
verified text.  That's the concern, right?  I've opened
https://bugs.gnupg.org/gnupg/issue2668 to record that concern upstream.

If you're talking about verifying InRelease, then that's a bit of a
special case, because it has a constrained format that we can rely on.
In particular, it's an RFC822 message, which means it has no lines with
a leading hyphen (-) and it has no preamble or footer outside the
signature.  So it should be possible to convert it manually to separate
files that can then be verified with gpgv and used independently.

Alternately, cdebootstrap could use Release and Release.gpg and avoid
InRelease.

Using detached signatures is probably a safer and saner approach where
possible anyway, and using gpgv will pull in fewer dependencies.

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20160904/42dae53d/attachment.sig>


More information about the pkg-gnupg-maint mailing list