Set the environment variable GNUPGHOME to the desired location.

I'm working on a solution for this problem, but since gpg-agent does now ignore
--no-use-standard-socket, how do I tell the agent daemon on commandline where to
create its socket?

Using the original file name does not make much sense because it is common to
delete that file. Maybe the creation/ctore date and key algorithm can be used
as a default.

With the extended private key format we could add a comment field for ssh.

The idea is to change the algorithm in the case that a full mail address is
given - and only a mail address. For both -r and --locate-key. g10/getkey.c
has get_pubkey_byname which implements --locate-key and already checks for a
mail address (IS_MBOX). This function needs to be changed to figure out all
matching keys an return the best one. -r should make use of that function also
if it is a mailbox.

Thank you!

You need to find a writable place for GnuPG 2.1 to bind its sockets to. If you
do, you can also use the smart card daemon. Using a smart card to store could
increase the security of your setup considerably. Also, I consider this an
integration issue, so talking to your distribution makes more sense imho.

Otoh, if GnuPG 1.4 fits your needs, you could continue to use that. It will be
maintained forever for compatibility with older PGP versions.

Fixed in 165f0ecebc8a68bff30d5255962a3b44d8113940. Will be deployed to the
webserver soonish.

I figured out that the custom_id property also works without an toc.

Ah, no. I don't _want_ to use pinentry, it's just what happens with GnuPG-2.0,
given that pinentry is installed and GnuPG is able to find it at that point. I
can very well live with the basic (blind) prompt from GnuPG-1.x (I think
pinentry's habit of displaying * characters for each passphrase character typed
is also _not_ an improvement). So, I'm using pinentry, because I don't have the
choice not to do so.

And, honestly, I find changing an application's behaviour such way it doesn't
work anymore like it did for years without even an option to get at least part
of the old behaviour back - I'm talking _only_ symmetric _de_cryption here, for
everything else I'm fine with the agent - is not really an "improvement".

I understand there has been considerable time invested in discussing and
evaluating options here, but this decision renders GnuPG worthless for a step of
security I've had and now I need to look up alternatives, with the tradeoff of
them being probably less thoroughly scrutinized, esp. in their implementation of
the cryptography part. Also not an "improvement".

If you want to use the pinentry mechanism you need the agent in GnuPG 2.1.
There is no way around that. You need to find a writable place for GnuPG to
bind its sockets to.

Note that this is not an "issue", it is an improvement. GnuPG has been split up
into several components, a process called compartmentalization. The agent is no
longer optional.

pinentry is used to enter the passphrase, during bootup pinentry-curses is in
use, after the GUI has started, a graphical version is used.

The major problem is that the gpg-agent tries to write to the root filesystem
when gpg is called to supply the key-material to LUKS. This fails with modern
GnuPG, stable GnuPG doesn't have this issue.

I am using Gentoo Linux AMD64 stable as operating system which stabilised
gnupg-2.1.15 a few days ago for general use.
In my LUKS setup GnuPG is used to symmetrically encrypt/decrypt a file
consisting the random data which in turn is the key for the LUKS partition in
question. So GnuPG does the part of requiring a secret for a required file to
get to the data in question, like a PIN to a credit card, both are worthless
without the other.

The process is roughly this:
The kernel starts and init (no systemd) proceeds to one step prior to checking
all to-be-mounted filesystems.
Now one or more partitions are found to be LUKS-encrypted with gpg-encrypted
keyfiles.
For each partition with such a gpg-encrypted keyfile gpg is called to decrypt
the keyfile and pass it to cryptsetup.
After all partitions have either been decrypted, the regular filesystem checks
are performed and filesystems are mounted as specified by /etc/fstab.

The crucial part is that up to the last step in the process the root filesystem
is still read-only and the agent's default location for the socket
(/root/.gnupg) doesn't allow creation of the socket.

Since my disk encryption relies on being able to enter the keyfile's passphrase
prior to being able to write to the root filesystem, I'm currently stuck with
GnuPG-2.0, which doesn't need its agent (contrary to its man-page, btw).

The bug tracker has a spam problem, so new users need to be approved. I did that.

Note that the gpg-agent *does* relay comments if the private key has one. If
the key resides on a smart card, the cards serial number is used. It uses
'(none)' to indicate that no comment has been set.

I agree that '(none)' while technically correct is not very helpful, I'll have a
look if I can come up with a more helpful fallback comment.

How do you supply the passphrase? Modern GnuPG uses the gpg-agent to ask for
passphrases.

Also note that 'S.gpg-agent' is not a file, but a socket. Nothing is written
there, it is merely used for interprocess communication. Are you sure that
there is no writable location that can be used to create the sockets?

Please tell us more about your setup. What operating system are you using, how
is GnuPG used in the LUKS setup?

I wish to work more with the bug tracker.

It seems you missed the creative commons links (on all pages).

Also some more:

• Download page contains links to gpg4win, gpgotools (mac) and rpmfind which

are all available over https.

• documentation page contains another http twitter link.

(Hint: The moartls browser addon for chrome and firefox is extremely useful to
do this)

Fixed in 1e6073ff.

Please clarify the plan a bit. Shall we use the algorithm currently used by
--recipient, the one used by --locate-key, or implement a new one?

another item for consistency is gpg-agent's different behavior between
--enable-ssh-socket and --extra-socket (and the undocumented --browser-socket,
for that matter, but since it's not documented maybe it's fine to just change
that one).

I have created two sample commits, pushed to

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=shortlog;h=refs/heads/justus/issue2700

The second one does indeed change translated strings. If I don't update
translated strings, then the messages will still refer to the old version of the
options, which will still work but won't show up in '--help'. Is there a
problem with updating the strings when I also update the .po files?

FWIW, the use of file suffixes to determine the content of a file is pretty
fragile. On Unix this is not used due to the availibility of the file command.

The recent gpgme version has enhanced detection capabilities (even better than
file) for OpenPGP and S/MIME file types. If there is a way to hook into the
Explorer to determine the file type and set an icon we might be able to add this
to GpgOL

Fixed in 8d370180.

There are a couple of ideas on how to use mail for key retrieval. We won't be
able to implement them for 2.2 but we should consider this for 2.3.

There won't be any changes for 1.4, though.

Please do that as soon as you have some spare time. Take care not to chnage
translated strings.

By renew you mean prolonging the expiration time?

To add this new default we should first add a --quick-set-expire command to make
it easier to change the expiration time. Or --quick-expire to match the name
used in --edit-key - I don't care. And of course gpgme needs a new API.

According to T1143 (aheinecke on Jun 08 2016, 07:15 PM / Roundup) the plan is that locate-key as well as -r uses a new
mechanism to figure oiut the appropriate key. aheinecke already implemented
this strategy in Kmail but we want to have it in gnupg proper.

If the given key is specified by a mail address the new scheme kicks in for
--locate-key and all keys given with -r. gpg finds all matching non-expired and
suitable keys and then computes the validity (WoT, TOFU, whatever). That is
list ordered and the top ranked key is used. Newer keys/subkeys are preferred
and thus in general there should never be an ambiguity. In case there is an
ambiguity, -r should return an error and --locate-key should return all those keys.

This bug supersedes T1143 and T1232.

Duplicate of T2359

gpgme 1.7.0 has been released and thus I consider this bug solved.

Also, most options join words with hyphens, but some don't.

Fixed in 1.7 with gpgme_op_keysign.

All done except for some news entries which are actually about http. Two
changes for cvs.gnupg.org will go online with the next page rebuild.

Yeah we recently had a lot of spam, thus the http trick.

Thanks for the list; I'll look at them.

SETREPEAT is an optional feature - thus I changed this to a feature requests.

I'm unsure about the compatibility issues with using a higher filename-length
limit.

gpgme 1.7 will have gpgme_op_createkey which takes "default" and
"future-default" as algorithm parameters. There is also a bunch of user
functions to make creating a key easy with gpgme.

This has been implemented in the repo to be released with 2.1.16.

This has meanwhile been done.

No bug, Use "cert" and not "certify".

@werner, if you prefer ntbtls over gnutls, okay. Can you add a link to ntblts
and outline the next steps. We'd probably need tls support for the web key
directory as well, so this needs a solution.

It is a hack in OpenKeychain to allow the use of several devices. Frankly, I am
not sure whether this is really a good idea: The security is limited by the key
for the least secure device.