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.

Done with commit d25db3c for 2.1.15

Yeah, at the moment I shoot scdaemon with SIGTERM whenever I need to use the PIV
app, which is rare, and have carefully avoided any kind of automated invocation
of the smartcard through scdaemon (e.g. my statusbar polls via ykinfo directly,
rather than invoking gpg --card-status.)

I know essentially nothing about smart cards or PC/SC's design, but what goes
wrong holding the card open shared rather than exclusively? Can other shared
lock holders do drastic things like insert or remove keys, causing scdaemon's
cache to become stale? I would have (naively) guessed that shared holders could
only do things like cryptographic operations which won't pose an issue to
scdaemon's cache. (Admittedly, cryptography is not side-effect free; counters
get incremented, random numbers get generated, but none of that is the kind of
thing that scdaemon caches, right?)

Thanks for thinking about this. :)

FYI.

https://lists.gnupg.org/pipermail/gnupg-devel/2016-August/031479.html
^-- In this experiment, I tried another half of supporting OpenSSH certificates.

I found that it doesn't work as I had thought.

I think that the lower level support of gpg-agent is ready to add this feature
of accepting OpenSSH certificates, but modification of OpenSSH will be required
too, so that it works well.

Currently, the OpenSSH certificate file itself is still needed even if ssh-agent
supports OpenSSH certificates. When it returns a certificate to ssh client, ssh
client only uses the information of the key in the certificate. It is the file
which ssh client uses communicating to the server.

Scdaemon grabs the device after its first use; it gets information on the
card/token and it operates (sign/decrypt) based on those information. If it
releases the device, it should get the info.
Current design of scdaemon is state-full: it caches the information on the card
so that operations can be soon done.
more state-less design could be possible, with the cost of each operation will
be heavy (by getting information each time).

I don't know the PIV app of Yubikey, but, in most cases, such an app can be
written stopping scdaemon beforehand (by a line of gpgconf --reload scdaemon, if
it's a script). It's a simple workaround for now.

PNGs are noe rejected.

Fixed with commit b5e16b0

I changed this ussie to a feature request.

Debian's codesearch shows that gpgme_op_assuan_transact is only used by gpa and
a configure test in kdelibpim for its own copy of gpgme. In gpa it is harmless
to enable this. The only effect is that a status line callback will see a
status keyword "#" and status callbacks should always ignore unknown status lines.

Let's enable it by default.

This was already mentioned in T2360 so let's not clutter the tracker.
Resolved as duplicate.

Duplicate of T2360

To piggyback something on this issue.

To quote T2359 (aheinecke on May 17 2016, 11:59 AM / Roundup):

e.g. an API to check which key: gpg -er aheinecke@intevation.de

I did not have groups on the radar for this. If a recipient is a group then
gnupg would use multiple keys in this command.

I think locate-keys would be a great mechanism to support this easily in MUAs.
When we change it that for a given mailbox only the single most valid Key is
returned we could also have the semantic that if then multiple Keys are returned
we have a group.

I have a possible solution pushed to branch justus/issue1955. The idea is to try
to parse the message with PINENTRY_MODE_CANCEL first, and should that fail, we
retry with the configured pinentry mode. Not sure if that is too hacky, or what
side-effects parsing the message may have that we must not do twice. Werner,
what do you think?

While the detection works now to distinguish between PGP and S/MIME data it
might be more robust if it would do some more sanity checking on the packet.

E.g. PNG Graphics are detected as PGP Signatures because they start with 0x89

But this is not super neccessary as for the use case of file extension support
valid data will be detected correctly.

I think that the charset header in the armor is not a good idea. In fact gpg
does not consider it at all. The armor headers are not protected and thus they
should not not chnage the semantics of the encrypted message. There is also no
way to keep this information after removing the armor or to re-create the header
from a binary message.

I consider a new flag for the Literal Data Packet to indicate theat the content
is a MIME message to be better. Standard MIME methods can then be used to
describe the content. Right now we only have an 'u' flag to indicate UTF-8
encoding (which to some interpretation of OpenPGP is anyway the default).
An 'm' flag would make it explicit that the content is MIME encoded and there
would be no more need to derive that info from the context.

I also created a set of examples messages. They are in
gnupg/tests/openpgp/samplemsgs/