Fixed with commit 23191d7.
This should be the same patch as used by Debian.

Done for 1.4.15 and 2.0.22.

Will do so.

D169: 384_verify_doc.patch

I'm reading in your response that you're not eager to change the behaviour of
--verify in this regard, right?

If that's the case, perhaps you can consider this patch to add a note to the
documentation, making it clear what is expected when using --verify on inline
signed files with auxiliary data. Afterall, we've seen several places where
--verify was used insecurely in the wild, so some warning may be in order.

Hm. The process disappears after some time. Maybe it just needs some time to
finish. Maybe not a bug anymore. Please take a look at it yourself.

Can you please take a look at it again? If I compile long_genkey.c and run it
via ./long_genkey async it leaves a process behind, which should better be killed:

ps aux | grep gpg
dl 7577 7.0 0.0 24416 1924 pts/2 SL 22:05 0:00 gpg
--enable-special-filenames --use-agent --batch --no-sk-comment --lc-messages
de_DE.utf8 --lc-ctype de_DE.utf8 --status-fd 4 --no-tty --charset utf8
--enable-progress-filter --display :0 --ttyname /dev/pts/2 --ttytype xterm
--gen-key -- -&5

What is the threat model for this? If you are able to ptrace a process you can
do all other kind of stuff, like replacing gpg with your own code. If the box
has been taken over, we are in game-over state.

Disabling core dumps is a different issue because a core dump leaves traces of
the process on the disk.

I think that original reporter's intention is to prevent attaching by ptrace.
By PR_SET_DUMPABLE disabled, ptrace PTRACE_ATTACH won't work any more.
This would be better if we care about kernel compatibility.
In http://bugs.debian.org/714107, I found that setrlimit64 doesn't work reliably
for 2.6.34 or older. PR_SET_DUMPABLE seems to work for even 2.4.x.

Yes. I think we're in agreement that MIME and detached signatures are the best way.

However, the functionality in gpg to check cleartext messages is there. If gpg
is confronted with a cleartext file containing auxilliary data, wouldn't it
better refrain from giving a positive return code when checking that file?

Hello Werner,

GnuPG uses setrlimit do disable core dumps. It has always done so. See
common/sysutils.c:disable_core_dumps. Do you have a test case which shows that
it does not work?

1.0.2 is more than 8 years old. The code chnaged a lot in the meantime. Feel
free to re-open if the problems persists with 1.4.x?

Pending for a long time; should be considered for 2.1

Fixed in master

This is an application problem. For example KMail renders the signed parts in a
frame with a different color so to visible explain what has been signed. Mutt
has a similar feature. We can't do anything about this in gpg than to emit
certain status lines and to output the signed data.

This is long known problem with signatures and not even the worst. MUAs
introduced ways to mitigate the problems 2 decades ago. The best working
solutions is to use PGP/MIME for mail and detached signatures for other data.

Fixed for 1.4.13 (e3e5406)

I would say this should go into 2.1.

This is not a bug. The description of --max-cache-ttl reads:

  Set the maximum time a cache entry is valid to @var{n} seconds.  After
  this time a cache entry will be expired even if it has been accessed
  recently.  The default is 2 hours (7200 seconds).

Thus even if you set the cache-ttl-ssh > max-cache-ttl, it will expire after
max-cache-ttl seconds.

May I ask for the status of this bug?

May I ask what happen with this bug?

Just trying to keep track of these bugs in Debian Bug Tracking System.

Sorry for reviving this bug, but, What is this implemented in gpg 1.4.x series?

Or this is going to be in the gpg 2.x series?

No, I can't reproduce the problem. I just came to check the status of the bug.
Thanks for the info werner.

The first example runs gpg on a file and displays what it sees in the file. The
--with-fingerprint only adds the fingerprint. The second example is a shortcut
for --list-keys --with-fingerprint and lists the keys known to gpg.

Given that running gpg on any file is not well defined; I would consider this a
minor bug. However, gpg 2.1 messes the output completely up and thus I need to
do something for it. But not for 1.4.

It was set to resolved in 2011 because I was not able to replicate it. Are you
now able to replicate the problem?

Hi!

These options are going to be removed from the manpage?

Hi!

Is this bug solved? And if yes, in what version is resolved?

The gpgme-config scripts goes along with the gpgme.m4 code. A .pc file won't be
able to do what we can do with this combination.

Please disregard my stupid comments about GPA. I was on the wrong track.

That is actually a bug.

I will consider that for 2.1. Doing it for 1.4 will break all translations and
thus I don't belive it will be an improvement in the end.

We don't see a reason for this. 2k is the current best practise. See the long
discussions on gnupg-users which pop up every few months.

I need to verify this. It is possible that we do a keylisting while importing
keys and the keylisting prints to stdout. If that is the case, we can't change
it because gpgme and scripts may reply on it.

Using --quiet for --refresh-keys makse sens, though.

You mean there is a useless process running which should better be killed, right?

Another user reported in this (I can verify it):

During a full refresh of the keyring, gpg seems to output all information
to STDERR and STDOUT. This makes it inconvenient to have a cron job to refresh
keys, because it can result in a very large and fairly useless mail.

Please ensure that normal output goes to STDOUT and errors and warnings to
STDERR so that problems aren't lost in the noise from this command.

Indeed some "normal" messages go to stderr and some warnings go to stdout.

This won't add a dependency on pkg-config. The reporter requests, that you
ship a .pc file, so packages dependening on gpgme can use pkg-config to
determine compiler and linker flags when building against gpgme. There is no
request to make gpa use pkg-config.

Done. Thanks.

In general I don't like pkg-config because it adds an extra dependecy above the
required libraries and introduces other problems. However, for GPA we already
have lot of dependencies and thus I would accept a patch.

Fixed for 2.0.19 (8b9fb19).

Fixed in GIT master (0ad03d2). Will go into future releases of all branches.

Fixed in commit 1ce38d7