I found another encoding error which renders the test data uploaded yesterday useless: Here is a bogus AEAD packet:

00000040  d4 84 01 07 01 00 6c 34  7c 37 83 24 2a 11 bc 1c  
00000050  bd 1a 76 da 93 8a
              [start chunk] 32 cd  80 a5 8e db 3a 7d 4a 40  
00000060  c5 0d 82 01 8d 64 7f 65  cd ca 58 d0 e7 db 3b 5e  
00000070  89 d9 1b c8 d9 93 1a 37  3c 0e a5 8f 4b 0d 9f db  
00000080  34 56 c8 f1 e9 b7 f5 0b  d2 53 4f 6c fd f8 e9 16  
00000090  cd a4 ae f6 7f 65
                      [tag] ef 5f  96 af 62 70 f4 30 27 37  
000000a0  68 61 95 0a fb 23
                [extra tag] a6 66  75 7a 47 bb 57 d3 da 5a  
000000b0  4d d1 c2 2f 43 39
                [final tag] cd 22  91 16 1d 92 17 1f f2 cf  
000000c0  0f c9 11 56 d0 a9

The stripped down log is

password is "abc". I have some comments in the commit logs.

Can you please show the output of these failing tests? I assume you are running on a 64 bit platform.

@Ainahir thanks for the info. However, your problem might be different because you are on Windows and not on Linux.
Please use for dirmngr --debug=ipc,dns instead of --debug-level=guru

Here is a file

The problem is still that other - non-gpgme threads - can still use getenv and friends without us noticing that. But I see no solution for this. In any case this code is the best we can do.

Hello Andre.

GnuPG stores key in a protocol independent manner. This allows to use the same key material for ssh, X.509 and OpenPGP - if you want that. A side effect is that it is possible to use the same key material also for several subkeys. Note that, unless you use --yes, gpg-agent will issue an additional prompt to request confirmation of secret key deletion. It even will show a warning if gpg-agent knows that the key is used for ssh. The thing here is that gpg-agent is picky about accidentely deleting a secret key. In general this is better than the other way.

Can you help me and tell me the AD for the last and the final chunk?
My current values are:

I will eventually look at this. However, sometimes the reason for such conditions can be documentation purposes. Thanks for pointing out.

With AEAD we can immediately check whether the correct passphrase is used. With CFB we can't do that and thus the checking is delayed until we can do the bulk encryption using the session key. At that point it is too late to check for other keys - well we could record that all and try again but that would make the code pretty complicate.

It was fixed with commit 641aae78 _after_ 2.2.5. Will eventually be merged into master.

Will go into 2.2.6

No more info received - assuming this has been fixed after 1.2.20

Will go into 2.2.5

I changed the wording to suggest the use of proper transport security.

Thanks for tracking this down. I'll fix.

Note that there is no standard for this. In particular the encoding of filenames with special characters are different in almost all implementations. I tried to find a common ground for our implementation.

This is a MUA thing. Do you ask whether we plan to add it to GpgOL?

See T3796

Sorry, we won't do this any time soon. We may even shut the Bitcoin thing down. I was too troublesome from a bookkeeping POV.

(automake should flag non-portable Makefile features - after all it is there to avoid gmake features)

Does this patch help? My artificial test confirmed that this does the Right Thing.

I don't think that -R is a good way to implement BCC - it would be better to encrypt it separately. But people may have different ideas on this.

/* Print all commands.  If a help string is available and that
   starts with the command name, print the first line of the
   help string.  */

For SETKEY this is not true. To change this we would need to have an "alias" flag to tell libassuan that setkey is an alias of sigkey. Not sure whether this really makes sense.

Can't replicate this with gcc's address sanitizer. I found a bug in kbxutil, though.
Can you post a bit more info than just line 1275?

That is just coincidence, ie. XDG_RUNTIME_DIR must be set to /run/user/$UID on you box.

Thanks for this research. Two weeks ago I also did some testing and started to implement a fast track way for simple encryption(for example without signing and filters). But your path to improve iobuf is probably the more general solution.

The --create-socketdir is not not anymore needed because the socket directory is meanwhile always created. We would need to handle the --dry-run in a special way here.

2.1.15 is a pretty old version. Please help us and try to replicate this with a 2.2 version and also give a log of the --delete-secret-and-public-key and --list-secret-key commands.