What you want to do is to make the configuration depend on the input data: The
keys are input data. This is not acceptable.

As it happend, I updated the locking code this week which now matches the one
used by GnuPG-2. The lock file now records the nodename of the box and if the
lock is held by the same node (machine) and the process does not exist anymore,
the lock file will be removed. Without taking the nodename in account we were
not been able to remove a lock file because the directory might be on a shared
file system.

This has been discussed several times on the mailing lists. You can't do that
because gpg needs to ask several questions. There are too many choices for a
command line mode. --sign-key makes it only easier in the most common cases. A
--force option won't help because you don't know which user ID you are going to
sign.

also sprach Werner Koch via BTS <gnupg@bugs.g10code.com> [2009.05.06.1111 +0200]:

Nope. Featurism without clear semantics. Use something like this

#!/bin/sh
fpr="$1"
shift
gpg --options myconf/gpg.$fpr.conf "$@"

Nope. Featurism without clear semantics. Use something like this

The roaming causes each PC to take a copy of the "C:\Documents and
Settings\<user>\Application Data\gnupg" directory at login. If 2 PC's login
simultaneously, they'll each get a COPY. They can then make separate changes,
but don't see updates made by the other user. When they logout, their changes
are uploaded back to the Profile server. The last person to logout overwrites
the changes made by the 1st user to logout.

Does the roaming mean that windows constantly syncs the two directories? If
that is the case, the missing locking was indeed a problem. However, depending
on how Windows does it, the new locking code won't help, because gpg does not
take a FileLock on the actual file but on FILE.lock.

File locking is now implemented for W32 (svn rev 4992).

The problem for me is that I'm using a Windows Roaming profile. That means I'm
using a COPY of my profile on 2 separate machines. Any changes on one machine
are not detected by the other. On logout, any changes are synched backl to the
Profile Server.
To get round this, I need to stop using the Windows Profile area to store keys.
I stumbled on this...
http://lists.gnupg.org/pipermail/gnupg-users/2008-April/033224.html
...and set my gpg.conf to the following...

Done in svn 4991.

Fixed in 1.4. svn rev 4990.

There are two problems: The first is that GPA uses GnuPG-1, I need to check
this but it should not matter because the problem in T1008 is that the
gpgconf tool from GnuPG-2 is missing. There is no problem using both versions
of GnuPG at the same time.

Check your gpgsm.conf and fix the option
debug-level
Valid levels are non, basic, expert, advanced and guru. See the manual or man
page for details.

Thanks for the info. This may be related to:
T1008
...where GnuPG2 doesn't get installed sometimes.

I know, however the checks do only basic checking and reject more exotic
addresses. Actually the specs don't say anything about the format of a user ID;
it is just a convention that they resemble a mail address.

You are the first one to report this, despite that GnupG for Windows is 9 years
or so old. It is not only a problem with several PCs but if you run several
several GPG processes on one box. The file locking is simply missing.

I assume you want to change $HOME/.gnupg to something like $XDG_DATA_HOME/gnupg.
Obviously this is not a good idea because ~/.gnupg is a weel established
standard for more than 10 years. We can't change this just for the purpose of
easier backup. However, there are simple workarounds like setting
GNUPGNOME=$XDG_DATA_HOME/gnupg or by using a symlink.

Arg, sorry for T1020 (bernhard on Mar 25 2009, 02:54 PM / Roundup) this was a paste and copy fault on my part.
Here again from gnupg 2.0.11 and gpgme 1.1.8 (as noted before):

You are using both times the same command line ?

Thanks for the hint. Interesting enough the result is the opposite.
With gpgme for OpenPGP the no_secret key is _not_ reported,
but
LANGUAGE=C gpgsm --status-fd 2 --decrypt hi.txt.gpg
[GNUPG:] ENC_TO XYAAAAAA 16 0
[GNUPG:] NO_SECKEY XYAAAAAA
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] DECRYPTION_FAILED
[GNUPG:] END_DECRYPTION

Please explain.

Just a short hint: If you report problems with gpgme you should add the option
--status-fd 2 to the gpg or gpgsm invcation. gpgme cares only about these
status lines.

Okay, fixed in SVN 4958.

From the the glibc manual (24.7.3 Process Signal Mask):

Thanks a lot. It did the trick. I consider it fixed.

2.0.11 released. No further response, thus closing.

Fixed in GnuPG 2.0.11.

Tested with gpgsm 2.0.10-svn4835 and pinentry-curses 0.7.4. Works fine now. I
did have to explicitly set GPG_TTY, though, to make pinentry-curses work, but
that's unrelated to this issue.

In configure.ac you will find

I have autoconf installed, so please let me know of possible ways to work
around it.

In my case the actual key is on an openpgp card. That may explain the
difference we are seeing.

quite right, I didn't check the code. I guess this can be closed then?

I can't replicate it with a card initialized the standard way and revoking the
encryption key. Will test later with only the subkey on the card. This is
using gpg2 or gpg-1.4.9 along with scdaemon.

Done in svn 4936

gpg does not work for the end of the data but starts decryption as soon as
possible. Depending on the terminal (console) which may lead to copy+paste
confusion.

Marcus: I don't understand cour comment: XAUTHORITY is passed through since 2.0.8.

No response, assuming it has been fixed.