Asking to create a revocation certificate is a good idea. Frontends can make
this the default then. However, this is something for GnuPG-2 and not for the
standalone version. I expect people using the standalone version to be smart
enough to create one. Should be discussed on gnupg-devel.

IIRC, the sematics of sign are too complicated for --multifile. If the problem
is just to avoid entering a passphrase several times, gpg-agent is very helpful
and solves the problem nicely.

Using multiple keyserver might be a usable thing but with the current
infrastructure it is not easy to implement.

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.

I use this text now:

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

Right, there is a nasty memory leak. It took me at least 6 hours to import an
8.5MB keyring. After the fix I was able to import the same keyring in 18
minutes including the trustdb check. Find attached a patch against 1.4.9 which
should also work against 1.4.7 and with slight adjustments for older versions.
It does work with GnuPG-2 as well.

D84: 219_gnupg-bug1034.diff

When I checked for a force-yes switch, I grepped for "force" and missed the
--yes switch. But also using this switch results in a prompt, so the main issue
persists.

fixed, thanks!

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.

D85: 218_doc_gpgv_texi.diff

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.

Thanks Moritz. I'm happy to try this out, but I'd need a binary if possible...

Fixed in 1.4. svn rev 4990.

I commited a patch to the trunk version in SVN, which needs testing. jonomcc:
could you try the SVN version? In case you don't have a build environment set
up, we can probably provide a binary snapshot.

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.