Oh sorry, never mind. Apologize for the noise. I accidentally looked at the
relevant file in 2.0.20 and thought it hadn't been fixed yet. Sheesh.

Fix will go into 2.0.21. Thanks.

Well, gcry_check_version is not called at all. The fix will go into 2.0.21 to
be released today.

That is not a bug. During import GPG removes invalid or unneeded parts,
reorders packets to fix bugs introduced by some older keyservers, and so on.
During export some other stuff might be removed depending on certain GPG options.

If you want to learn about the details please write to the gnupg-users mailing list.

Here are the example keys:

http://pastebin.com/cseQ0z8j

I can't replicate your problem. You need to make sure that gpg is able to
connect the agent. This either done by setting GPG_AGENT_INFO properly or by
starting the agent like

cd myhomedir
GNUPGHOME=$(pwd) gpg-agent --daemon /bin/sh

and then run gpg in that shell.

Can you please at least acknowledge whether these are bugs or not?

Fixed for 2.0 with commit 110b52f.

Thanks.

Problem seems solved; reason very likely found.

After years of taking a break from GPG, I took the work up again. First I
upgraded to GPG version 1.4.14 (the currently latest version). Then, in
reviewing my previous work, I found that in the interprocess dialog between my
program and gpg.exe I had been sloppy and had caused race conditions. In the
process of improving these dialogs, the described problem disappeared, i.e. did
not come up again despite some intense testing. I hope it stays that way!

Thus, although I cannot put my finger on "the one" code change that did it, I
tend to think now that the problem has been mine from the beginning, namely that
I had programmed race conditions. The intermittent nature of the original
problem supports this assumption.

I apologize for any inconvenience that has caused.

Hmm... wondering then however, why implement different behavior for --status-fd
set?

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.

Actually this is a feature. Ever tried to work with a bunch of messages all
encrypted to many hidden recipients?

FWIW, recall that PGP is broken as it did not (does not?) use UTF8 but assumes
everything is ASCII. Thus we sometimes find weird charset conversion. GPA has
a heuristic to at least detect Latin-1

Reporter's intention would be:
Given a public key with user id="", importing that key fails.

I think that Andrew's name in Chinese in UTF-8 cannot be interpreted as iso8859-1,
it goes as is, but usually it is interpreted as iso8859-1 as a fallback.

If you are sure it's utf-8 encoded, you can use --utf8-strings option.

This bug is still there in 2.0.20.
It would be better to add following line in main of gpgv.c.

gcry_control (GCRYCTL_INITIALIZATION_FINISHED, NULL);

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.

Fixed in 212a325d428e0ab5c51c42a3ea33efb21ad1f79f

I just backported the new ssh-agent code from master to the 2.0 branch. Thus
2.0.21 will have this support.

Thank you.

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?

1.13 and 1.14.
3.82.
GNU/Linux.

Which automake version are you using?
Which version of make are you using?
Which OS are you using?

Lines 74, 75 and 76 of agent/Makefile.am are copied near the end of
agent/Makefile.in and then to agent/Makefile. Because of the first of them make
exits. `Makefile:1565: *** missing separator (did you mean TAB instead of 8
spaces?). Stop.'

I can't see any problem with this Makefile.am. Maybe your automake version is
broken.

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?

Please recall that gpg is a Unix command line tool and as such it need to stcik
to common conventions. Only messages which are deemed to be necessary are
printed. Chnages to the key generation dialog would be veryhard because gpg is
used by several other programs as a backend and they assume a certain order of
prompts.

I suggest that you use one of the graphical frontends for key generation.

My mistake, I missed this part: "This example assumes that two
marginally-trusted keys or one fully-trusted key is needed to validate another
key. The maximum path length is three."

Thanks for your answer, I'll do that then.

Best regards

Loïc Gomez

In order to work around this potential bug I do the following at the moment:

1. Store: (a) Export the ASCII-armored *secret* key together with its subkeys. (b) Export the ASCII-armored *public* key together with its subkeys.

2. Restore: (a) Import the ASCII-armored *public* key together with its subkeys. (b) Import the ASCII-armored *secret* key together with its subkeys.

The actions [1.(b)] and [2.(a)] should not be necessary if there was not this
potential bug.

I further tried to find the action that causes the potential bug with an another
test key as follows:

1. Create a certify-only RSA4096 primary key.

2. Store the public keyring with: (a) cp ~/.gnupg/pubring.gpg{,XXX}

3. Export the secret key to an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --output 0xEEE9979BE8C80E95.pub.asc.txt --

export 0xEEE9979BE8C80E95

4. Export the public key to an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --output 0xB6BF97893ACA0C17.pub.asc.txt --

export 0xB6BF97893ACA0C17

5. Delete the public and secret key with: (a) gpg --delete-secret-and-public-keys 0xEEE9979BE8C80E95

6. Import the secret key from an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --import 0xEEE9979BE8C80E95.sec.asc.txt

7. Compare the previously stored public key against the new one with: (a) diff -q ~/.gnupg/pubring.gpg{,XXX}

8. Repeat action 1. to 7. by: (a) Adding a sign-only RSA4096 subkey. (b) Adding a encrypt-only RSA4096 subkey. (c) Change the expiry date of the encrypt-only RSA4096 subkey.

ERROR: *Changing the expiry date*, exporting, purging, importing the primary key
with its 2 subkeys makes the first sign-only RSA4096 subkey disappear from the
pubring.gpg file but not from the secring.gpg file.

If you want to rely on the exit coide, you can't use gpg. There are simply too
many things to consider and everyone has a different policy. I commonly use AWK
scripts to implement such policies by parsing the --status-fd output.

The tool you might want to use is gpgv which has been designed for these
purposes. In fact, it is used by all Linux distros to verify the integrity of
the downloaded packages against a specific keyring. Please check out the gpgv
man page.

It has been told for ages that the value of the exit code is not a reliable way
to get information from gpg. Use the --status-fd information.

To be useful bug report, please specify version number of your program. Also,
please show us your configuration file (if any). Specifically, do you have
enable-ssh-support option for gpg-agent?

To diagnose, please create a file .gnupg/scdaemon.conf with something like:

debug-level guru
debug-all

log-file /var/tmp/scd.log

Let us know the content of the file, when you see the problem.

Actually, gpg should not open the keyfiles at all. Well, unless you have enabled
the SELinux hacks. In that case we better register the keyfiles. The fix seems
to be harmless and thus it makes sense to apply it.

Patch has already been posted to the mailing list.

D174: 375_0001-checks-do-not-access-files-outside-of-build.patch

Will be fixed in 2.0.20.

Thanks for the reminder.

Duplicate of T1467

You should read the intro about becoming a registered user on bugs.gnupg.org. I
now changed your rule to User so that you may comment on other bugs.

What version of GnuPG is that?

Pending for a long time; should be considered for 2.1