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.

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

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

Fixed in svn

I think the easiest fix is to use /bin/pwd at both places.

Not a bug - sorry. bash returns a different value for pwd on my system than
does sh/ksh. This is because I have a symlink in my path.

It requires a POSIX shell and as far as I can see there is no dependency on a
non-standard feature. In particualr the check:

Duh, this is already implemented:

Thank you for the information, with it I will be able to alter behaviour on the
fly (via system variable) but anyway, it would be really great gpg could pass
an argument -- I think it is a bit more elegant way to control the behaviour.

We can't do that because gpg2 requires gpg-agent (not to a 100% right now but
eventually there will be no way without gpg-agent). Pinentry is a property of
gpg-agent and you can control which pinentry to use by using a symlink or
gpg-agent's option --pinentry-program.

Duplicate of T950

Right, this is the second point in T950. I am closing this request therefore.

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

This is a good feature request, but it requires some coding to make it work. I
think that this should be done via a context popup menu on the keylisting
entries (in addition to a menu entry).

Implemented in 0.10.x