Right 2.2.21 fixes a long standing bug in symmetric encryption in that the configured passphrase constraints were not checked. Eventually we will add a second sec of constraints here but for now the same constrains as for private key protection are used.

No info received

I am not any longer interested to see the real cause; eventually we will replace it anyway with a modern CreateProcess.

Reconsidering this: Running the test suite with gpg1 is not a proper use case. gpg1 may be installed in addition to gpg but it should never be used on a build machine solely.

I don't see any error here. There is a trailing LF on the binary data which gpg rightfully complains about.

As of today we don't want to maintain another binding; see T3395

The Python bindings are troublesome enough; as of today we don't want to maintain a Perl module.

No info received in3 years.

Has already been fixed with T4061.

C part done; C++ interface is not yet done.

Well, it changes the behaviour on error and thus it should not be backported to 2.2 so that existsing error reports about corrupted data don't change. Fine for master.

It might be related to T4257 - try with -j4 for now which is what I use for building.
For further investigations we need to enable tracing using

GPGME_DEBUG=8:gpgme.trc  make check

Probably the same as T4257

We can't do anything about it except for corner cases which we won't do right now. In case there will be an easy solution to help Debian please re-open this bug.

Sorry, I can't replicate this

From 1.14.0 on these functions will return a Not Implemented error and the documentation has been removed.

Its a year since I worked on the mentioned wait code change (wk/new-wait branch) and I more or less forgot about it. it will to risky to release that as 1.14 so this change and the fix to this bug needs to be postponed to 1.15. Sorry.

I have also relaxed the test in gpgme for that GnuPG version.

See T4897 for a patch to gnupg.

It turns out that a test case in GPGME fails with that version. This is due to a regression I introduced in the passphrase repetition code for symmetric encryption. This will be fixed with the next GnuPG version; in the meantime you may use the patch F1646254.

It is a pecularity of the test case. A new release is long overdue anyway, so please have a few days patience for a new release with a foxed test case.

To change the expiration date, I would suggest to use

Pretty please write a useful bug report; we need information on versions, OSes, compilers, any special environment, and all the steps you did to get the build failure. The configure run already prints a lot of useful information; you may want to extract them or provide a complete build log.

Creating is not that useful - we prefer modern curves anyway.

I think that retrieving a parameter in compressed format is all what we need as per API.

Because a few minutes don't matter. If you have the time to figure the reason out, please go ahead. It might be that we take the timestamp in the addkey case earlier and only set the expiration date after the key has been created.

The default for GnuPG 2.2 is still 2048 (Debian changed that in their distributed version). The reason for this is that we don't want to generate such keys but move on to Curve25519 for the new defaults.

Duplicate - see T4702 instead

I won't fix it. In fact it can't anyway be completely fixed because gpg has code to make sure that a new key is at least one second newer than the previous generated.

It has now been implemented for all types of symmetric encryption (not just -cs). To go into 2.2.21

The first, I guess. The problem is that you are technical capable of _decryption_ but gpg does not allow this because for some reasons the key is arbitrary limited to signing. A warning message should be printed in thus a case but decryption should succeed.

The qualitybar has now been removed from 2.2 and master.