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/

We got it for 2.1: -f or --recipient-file

The only reason I can see that scdaemon is not started by gpg-agent are
processes which run before a login, for example from PAM. But then the
autostart feature probably not needed.

hm, if there's a guarantee that scdaemon will only ever be launched as a
subprocess from gpg-agent, then maybe we don't need it.

If there's ever any expectation that some other program will launch scdaemon,
then it would be nice to use the unified launch mechanism provided by gpgconf.

Gpg4win 2.3.1 and 2.3.2 included 64 bit versions of gpgol.

Do you really want to use it? The problem is that you won't have a Pinentry and
some other minor goodies. The better way is to let gpg-agent route command to
scdaemon. For example

  gpg-connect-agent "scd help" /bye

shows scdaemons help.

Currently, there is no need for alignmask API. Implementations that we have at
the moment can handle unaligned data and some have fast paths for word-aligned
in/out buffers (which malloc can provide).

We could add section in documentation about appropiate memory alignment for best
performance, and tell to align buffers to cacheline size.

Fix for the difference in detection of armored vs. binary detached signatures
was trivial so I've pushed it with rev. 570bf2a

Looks good to me know. I'll start using it in Kleopatra and we will see what
breaks :-)

Have not tested different S/MIME messages yet.

Talked to werner about it. The way something like trust-model should be
switchable would be best to handle with profiles.

There is at least one profile planned for EasyGPG. Something like "Silent" or
automated. Riseup and VSNFD will probably also want to create profiles.

I think apply-defaults could be extended for this with a defaults file for each
profile.
Then something like:

gpgconf --list-defaults

    List all available default files.

Where the output format could be similar to list-components.
name:description:filename:

filename is the path to the config file.

Then --apply-defaults could be extended to take an optional filename as an
argument. (Like --list-config, --check-config)

With --dry-run it should only check if all the settings marked as no-change are
set correctly and indicate it through the return code.

For EasyGPG I think a config file could be:

• gpg-agent max-cache-ttl [change] 30758400 gpg-agent default-cache-ttl [change] 30758400 gpg trust-model [no-change] tofu+pgp gpg auto-key-retrieve [change] gpg auto-key-locate [change] local,wkd,dane,pka,cert,keyserver

Thanks.

I've created some examples to test it. They are all done with alfa@example.com
test key. Found an issue through that.

-ba (detached ascii armored signature) is detected as PGP-Signed and not as
PGP-Signature.

examples/plain.txt.asc: PGP-signed

A discussion about KMail handling PGP/Inline encodings [1] also makes me wonder
if data_identfiy should also return the output charset of text messages if it is
provided in the Armor Header. Afaik there is currently no API in gpgme to check
this and semantically It would make sense to me to parse this in identify, too.
But this is more of a question wether or not you think it makes sense to do this
directly. I'm not strongly opinionated about this.

1: https://bugs.kde.org/show_bug.cgi?id=248058

Done with commit cf37a57.
Note that only the first 2k are inspected.

Binary PGP messages are now detected. Not well tested but the run-verify test
tool can help to check the feature.

I need to implement a partial OpenPGP parser to decide what a certain PGP
Message is about and also bot all binary OpenPGP files. Please have some patience.

(that last comment was with 2.1.13)

fwiw, when i'm on a network that doesn't support IPv6, i get this:

0 dkg@alice:~$ gpg --send $KEYID
gpg: sending key REDACTED to hkps://hkps.pool.sks-keyservers.net
gpg: keyserver send failed: Invalid argument
gpg: keyserver send failed: Invalid argument
2 dkg@alice:~$

in dirmngr's logs:

2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L3: ASSERT: mpi.c:246
2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L5: REC[0x7f61f400fc10]:
Allocating epoch #0
2016-06-17 19:30:17 dirmngr[27999.2] can't connect to '2001:ba8:1f1:f2d4::2':
Invalid argument
2016-06-17 19:30:17 dirmngr[27999.2] error connecting to
'https://[2001:ba8:1f1:f2d4::2]:443': Invalid argument
2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L5: REC[0x7f61f400fc10]: Start
of epoch cleanup
2016-06-17 19:30:17 dirmngr[27999.2] DBG: gnutls:L5: REC[0x7f61f400fc10]: End of
epoch cleanup

I think this instance of dirmngr was started on a network that has both IPv4 and
IPv6.

if i do:

     gpg-connect-agent --dirmngr killdirmngr /bye

and then try the --send again, it goes through fine.

Would it be possible to also detect if data should be decrypt_verified or just
verified?

I'm having trouble with PGP MESSAGES that can be either encrypted or Opaque
Signed, or nothing.

If I do a decrypt_verify I get a No Data error in the result because decryption
failed. Should I just ignore No Data error and check for the status of the
signatures in that case?

I did not see anything in the FAQ dealing specifically with the GUI not
working. That is what this bug is about. I agree that changing the cipher-algo
should be done cautiously, but either the front-end should not permit it to
appear to happen, or the front-end should actually do the expected behavior
(namely, changing the config files).

Just noticed this issue as it was mentioned in T2359 which is "my" issue
about this topic ;-)
I've actually implemented the algorithm outlined in T1143 (dkg on Sep 23 2009, 06:53 PM / Roundup) in libkleo/ QGgpME
for a better opportunistic encryption support in kmail (
https://phabricator.kde.org/T2520 )

Werner told me that something like that will be done in GnuPG itself. Afaik the
current plan is to have --locate-keys use a similar algorithm to return exactly
one "best" key if a mailbox is given. And if I understood werner correctly this
would then also be the key used when you would do a "gpg -er <mailbox>"

Should this be closed as Superseded?

related: T1143

Fixed in the repo (commit 536c721)

We have meanwhile implemented such a check.

gpgkey2ssh has been removed from master (2.1)

Most thingd have probably been implemented in the meantime.

7257ea2 switches to none.

There is also a new option --with-subkey-fingerprint which keeps the compact
fingerprint format also for subkeys. The Lead-in text for fingerprints n the
listing is in any case not anymore printed if keyid-format is none.

Just pushed the --keyid-format=none feature. Changing the default will be done
with another commit.

Replacing revoked keys made me wonder if we actually need an auto-refresh key.
If we try to return one valid key with --locate-keys wouldn't it make more sense
semantically if we use the auto-key-locate mechanisms with locate-keys when a
key is expired in the local store?

This would also work better for revoked keys where a Parcimonie style auto
refresh would pick up the revocation and locate-keys would then look for a new key.

How do you plan to handle the case that "local" lookup only yields expired or
revoked keys. Will GnuPG then automatically fall back to other locate-keys methods?
This would be my wish so that a MUA / User of that command does not have to care
about that case :-)

This is the current output with keyid-format=none

pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31]

80615870F5BAD690333686D0F2AD85AC1E42B367

uid [ full ] Werner Koch <wk@gnupg.org>
uid [ full ] Werner Koch <wk@[...]>
uid [ unknown] Werner Koch <werner@[...]>
sub dsa1024 2011-11-02 [S]
sub rsa2048 2014-01-02 [E] [expires: 2016-12-31]

The problem I have is how to decide when to use the compact fingerprint format.
My idea is to always use the compact format unless --fingerprint switched back
to the old format (which is easier to read).

I started working on this.

I tried it but I think it looks prettier without. A rationale might be that the
fingerprint is a property of the "pub" (public key) and the line should be
considered a continuation line.

This looks great to me. I've always been frustrated by the c+p difficulty.

Does it make sense to put an "fpr" at the beginning of the fingerprint line, to
match with "pub" and "uid" ?

For example:

pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31]
fpr 80615870F5BAD690333686D0F2AD85AC1E42B367
uid [ full ] Werner Koch <wk@gnupg.org>

Have you started work on this change or would you like patches?

The current --with-fingerprint output is

pub dsa2048/F2AD85AC1E42B367 2007-12-31 [SC] [expires: 2018-12-31]

Key fingerprint = 8061 5870 F5BA D690 3336  86D0 F2AD 85AC 1E42 B367

uid [ full ] Werner Koch <wk@gnupg.org>

One problem I have with this format is the c+p of the fingerrpint is
not easy, because you need to mark the entire fingerprint and then use
quotes to use it. What about changing the default format (i.e. w/o
any fingerprint options to

pub dsa2048/F2AD85AC1E42B367 2007-12-31 [SC] [expires: 2018-12-31]

80615870F5BAD690333686D0F2AD85AC1E42B367

uid [ full ] Werner Koch <wk@gnupg.org>

or

pub dsa2048/1E42B367 2007-12-31 [SC] [expires: 2018-12-31]

80615870F5BAD690333686D0F2AD85AC1E42B367

uid [ full ] Werner Koch <wk@gnupg.org>

or

pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31]

80615870F5BAD690333686D0F2AD85AC1E42B367

uid [ full ] Werner Koch <wk@gnupg.org>

or aligned in some other way?

Personally I would like to keep the long keyid at least for subkeys
because it makes the key listing easier to read and forced selection
of a signing subkey easier. However, removing information which is
in most cases useless and partly dangerous has a higher priority.
Thus a listing of my key may look like this:

pub dsa2048 2007-12-31 [SC] [expires: 2018-12-31]

80615870F5BAD690333686D0F2AD85AC1E42B367

uid [ full ] Werner Koch <wk@gnupg.org>
uid [ full ] Werner Koch <wk@[...]>
uid [ full ] Werner Koch <werner@[...]>
sub dsa1024 2011-11-02 [S]
sub rsa2048 2014-01-02 [E] [expires: 2016-12-31]

To implement that I would indeed suggest a keyid format "none" which
will be the default and select the above new listing format.