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.

Duplicate of T2379

(btw, "fingerprint" should be 40 hex chars, not 32 as if suggested)

For modern gnupg, we no longer support v3 keys, and we're considering making
--with-fingerprint the default (see
https://lists.gnupg.org/pipermail/gnupg-devel/2016-January/030748.html), so i
think this suggestion should actually be reconsidered.

Not really making it simpler but --quick-gen-key can now take an expiration date.

Let's keep this bug open to track other improvements.

Ok,
Let me summarize how I understand the workflow is supposed to be:

• Generate a Key with the limited batch keygen.
• After key creation add subkeys as wanted with --quick-addkey
• Add additional UID's with --quick-adduid

I think I can work with that.
For full flexibility T2364 would be nice so that one could create a certify
only key this way and subkeys for everything else.

But yeah thats icing on the cake.

Still does not solve the Problem how to figure out which algrithms with which
parameters / capabilities are supportet but meh, I guess you can't have everything..

We also have --quick-addkey now.

We now have gpg --quick-addkey fpr algo usage expire
(for2.1.13)

Thanks!

$ gpg mBank17044.asc
pub rsa2048/375EB336C8086B9E 2015-01-19
uid AR17044 <XXXXXXXXXXXX@mbank.pl>
sub rsa2048/75E684B9017985DF 2014-12-29 [expires: 2016-01-20]

[uid redacted]
As you can see, the encryption subkey expired in January. Thus the holder of
the key does not want you to encrypt to this key after that date. We know that
GPA should give a better error message. I'll change your report to a wish to
implement this.

Duplicate of T2171

CRL detection is not really important. But detection of binary data is so that I
can properly handle .pgp and .gpg file extensions.

Detached signatures are also important so that I can look / guess for the signed
data and setup the verify operation accordingly or handle it in the GUI if no
Data is found. Maybe we can use flags for this so we don't break the current
behaviror that does not distinguish between detached signatures?

FWIW: pretty printing a time has a problem with i18n. It is too different for
gettext to handle.

That might be an option like '--pretty-expiration KEYID' that simply outputs in
a human readable format how much time is left before the key KEYID expires. That
simply saves the user from doing id mentally. Furthermore, the output could also
be made script-eatable