Gook luck on Solaris with this suggestion ;-)

Gook luck on Solaris with this suggestion ;-)

For the record, the typical response to "it doesn't work" support requests for keys.o.o still comes down to killall dirmngr.

I write a prototype in Python using pyassuan:

Fix pushed to master. Updated graph:

Reagarding the OpenPGP specs: there is a new draft with LOTS of changes to already agreed upon formats and conducted interop tests. Almost everything we implemented in GnuPG and RNP has had rough consensus in the WG. Minor things like AEAD chunk size were the contested pieces. However, now they want to change everything with the possible outcome of discretization the long established trust in the stability and durability of the PGP data and key format.

Great, thank you very much!

Thanks for notifying. Will be fixed in the next release (mid Apri).

Sorry. While v5 things in the specification is still in flux, from the viewpoint of the implementation, this patch is 100% valid and it makes sense.

Fixed in master and 2.2 branch.

You are combining two concepts here -- the KDF and the AEAD cipher itself (at least from the FIPS terminology). I would like to avoid mixing these two together in the new API. If you would like to implement the SSH/TLS KDF, I would suggest to use the kdf API you already have. Then we are here left only with a new geniv API to implement. In the T4873 I mentioned example how it is now used in libssh using libgcrypt, which implements the iv increment outside of the libgcrypt:

Thank you for the report.

I located the cause; Current implementation cannot parse the data like:

2611:d=5  hl=4 l=1632 cons:      cont [ 0 ]        
2615:d=6  hl=4 l= 500 prim:       OCTET STRING
3119:d=6  hl=4 l=1124 prim:       OCTET STRING

Is large change to cipher API really needed (new open/encrypt with less flexibility)? How that would affect performance? Would following new interfaces to gcry_cipher API work instead?

• gcry_cipher_setup_geniv(hd, int ivlen, int method): for setting up IV generator with parameters such as IV length, method id (RFC5116, TLS 1.3, SSH, etc), (other parameters?)
• gcry_cipher_geniv(hd, byte *outiv): for generating new iv: generate IV using select method, set IV internally and output generated IV to 'ivout'.
• gcry_cipher_genkey(hd, byte *outkey, int keylen, int method): for generating keys, generate key internally with parameters (method id, other?), setup key internally and output generated key to 'outkey'. (how keys from key exchange protocol be handled? using existing setkey?)

I went through my test files and found that --enarmor on zero length input file did no longer work. I made separate patch to fix that issue, which then also needs another approach for handling compress issue noticed earlier:

The mails from these days still contain the following header:

List-Post: <mailto:gnupg-devel@lists.gnupg.org>

which is probably causing the mail client directing the mails to this address. Is there a way to change or or make it an alias so it is easier for people to use the mailing list without finding this issue?

Should be fixed.

Ack from me for new 0005 and 0006.

More things to be considered:

• How to connect scdaemon
• How to invoke scdaemon

The patch for T5834 (https://dev.gnupg.org/rMad3aabdd8a64156c7e3a75d695ae1ab2c4bec841) was already applied to the build of GPGME 1.17.0 for Focal, as I did browse the list of latest GPGME bugs first before reporting this bug. Attempting to build with the latest GPGME 1.17.1 (with the included ABI patch) results in exactly the same FTBFS for i386 only, so this does appear to be a distinct issue not related to that of ABI backwards compatibility.

Does this look ok to push to master? @werner @gniibe

Please see T5834 which is fixed in 1.17.1

Fixed in 1.17.1

Note the ABI bug the Qt version of 1.17.0 which is fixed with 1.17.1 (T5872)