Also: feel free to add the link to this issue and if it does turn out to be a
problem with GnuPG add any information here. Thanks!

You can implemnnt something like this using 2.1 and the --extra-socket feature.
Give the extra socket appropriate permissions/ACLs

This will eventually be done but not right now. I keep this bug report as a
reminder.

I granted you permissions to edit other bug reports. However, this patch is not
required.

But the secret subkeys are not used. Or well, the keyflags should be taken from
the public key. That might not always be the case - in particular not if you
re-create the public key from the secret key.

You can of course repair it using 2.1 because there --export-secret-key takes
the public key and only adds the secret parameters.

What's not clear to me if it is possible to recover a private key that is
damaged this way? If you change expiration with 1.4, the self-signatures are
lost and some key flags are changed. Is it possible to recover from that? That
is the problem I'm concerned with -- if it isn't possible to recover, it seems
people end up with damaged secret subkeys after changing expiration date on a
subkey with gnupg 1.4/2.0.

There are 2.1 beta versions which support this.

Sorry, I don't know what a Basket Note Pad is. Please report there first.

Bad news, though that .c/.cpp file exists, it does not seem to get built into
Android. I have tried building against android-14, which is after that file was
introduces, and no luck. I also tried looking for it in the libs, and its not
in the .so or .a libs. Running this gives me nothing:

$ strings /opt/android-ndk/platforms/android-*/arch-arm/usr/lib/* | grep atfork

For 1.4.1 I reverted the default for to --disable-fd-passing. This should fix
the immediate problem. If you can find the actual reason for this problem,
please follow up and change the status back to chatting.

May I ask what happen with this bug?

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

See also T1109 which describes the problem in a few words.

Duplicate of T1109

If gcc's print format checks would only support custom format string extesions
we could easily implement a filename specifier. Without that we are not able to
use format string checks which is something I don't want to miss.

It seems this is not important enough to implement an extra filter for this case.

We will address this in 1.6. At least for ELF systems supporting the weak
pragma and for W32.

The exit code alone is not sufficient to return a useful error status. Thus
Marcus is right that we can't do much and gpgconf should be used to validate the
configuration.

2.1 will fix that.

A colleague just observed that expiration dates are also missing when
--list-secret-keys is used without a matching string.

That seems to be a bad interaction between gpg-agent and keychain. AFAICS both
programs try to do the same: gpg-agent also implements the gpg-agent protocol.
It needs to be enabled, though.

Thanks.

May I ask for the status? Seems, there were no objections.

Wen can look into this during the development of 2.1.

I had a go at doing this in sections. I used:

Agreed for the manual page. We will think about this.

I leave this decision to you. I agree to the reporter, that everything is a bit
"wildly" ordered atm. However, I cannot speak for an unexperienced user. I've
asked the reported for feedback/his opinion.

Quite right, claws actually does invoke AC_SYS_LARGEFILE.

An admin saw this suggestion in front of a user and got annoyed
that the recommendation

"the trustdb is corrupted; please run \"gpg --fix-trustdb\".\n") );

in tdbio_invalid(void) gnupg-2.0.12 did not work.

not a bug or - if at all - a bug in glibc. Further discussion please on the ML

Enter a "?" on the prompt and it will show you the valid characters.
We can't change this right now because this would break all translations.

Marcus, I think we can close this now.

GPGME has now been thoroughly tested in a multi-threaded environment (Kleopatra
on Windows), and it seems to survive. Closing this vague report.

Closing the report about porting to a non-supported target.

Actually, gpg can not do much if configuration options can't be parsed. GPGME
does not see the exit code due to the double-fork approach.

In principle, this can happen on Un*x systems, too. There is no guarantee about
the filesystem encoding. Glib has special interfaces for filename conversion
(G_FILENAME_ENCODING) to deal with this.

Closing this report, as nothing happened in half a year with regards to the
finnish translation.

Due to time constraints, the 0.9 series of GpgOL is no longer supported.
I am sorry for this inconvenience. Gpg4win/2 will soon be released featuring a
heavily rewritten GpgOL.