Can someone please check this?

We won't do any changes to 1.4 anymore. You need t wait for 1.5; sorry.

You are keeping me pretty busy :-)

kbxutil is more a debug tool and may change at any time. I don't think that a
man page is useful.

See these threads for example:

The internals are already set for multiple keyservers (opt.keyserver is a
strlist, etc.) I had to implement it for the auto-key-retrieve feature, which
does support multiple servers.

On Thu, May 28, 2009 at 03:03:07PM -0000, Werner Koch via BTS wrote:

Sorry, I mixed this up with gpgshell. Actually I might have done that for a
long time and ignored the existance of that project. Too bad.

Change 5028 for 2.0.

See the recent threads on gnupg-devel for a discussion on this topic.

Change 5024 for 1.4. Will do 2.0 shortly.

Interestingly enough, it's no longer the default in libcurl. We'll have to do
it for both the libcurl and emulation cases.

This is the occasionally-requested "--unwrap" command which would stop
processing after a single layer of the file. I.e. convert Enc(Sign(data)) to
Sign(data).

Thanks, that did it.

D87: 223_default-preference-list-change.diff

The options --batch or --no-tty will help you.

Forget the second part. It prints this message only, if it indeed needs input
and giving --yes works in this case too. So there was a fault on my side.

Maybe we misunderstood(?). The gpg-agent is not used.

I don't want to decided whether thisis a bug. The thing is that using gpg with
gpg-agent is more of a temporary solution than something we want to work as
clean as possible. For such use cases it is better to use gpg2.

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

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.

D85: 218_doc_gpgv_texi.diff

Done in svn 4991.

D83: 216_0001-don-t-install-gtk-entry-select-on-focus-settings-p.patch

GnuPG Shell is, and always has been, released under the GNU General Public
License.

The coupling to secmem is why I propsed this for pinentry not for GTK+ itself.

Too much mainenance work. It is also closely coupled to the secmem stuff. You
better ask the GTK folks to add such a widget.

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.

Please explain.