Thank you for your report.

New API gpgme_op_random_bytes is now in master (gpgme 2.0). Use tests/run-genrandom --help for testing. Extra features will come soon.

Finally removed with gpgme 2.0

Okay, thanks!

Fixed in master and the new gpgme-1.24-branch. Thus this fix will be in 2.0.0 and 1.24.2

I am pretty sure this was my fault: rM62b6c1f16 is the culprit.

VSD-Beta-481: Encrypting/signing with gpgtar on the cli and decrypting/verifying with Kleopatra works

works with VSD-beta-478

I have replaced the expiring test key with a new non-expiring test key.

@ikloecker: Do you still have the private key for tests/json/key-with-revokers.asc somewhere? We need to remove the expiration date due to T7471.

(ignore the last commit, I assigned the wrong task to it)

In T7262#195642, @ametzler1 wrote:

I read this as bumping the version-number e.g. from 1.24.5 to 2.0.0 without e.g. bumping the soname or changing the api_version as specified in the .pc file. (FWIW I think that is a great plan.)

We'll do this with QGpgME 3. And it's easy to add new functions by using the NVI pattern and, if needed, virtual functions in the attached private classes. I've been using this technique for quite some time now.

Ah, ok I understood it as "we will change the soname for other reasons e.g. so that both versions are co installable but we will not break ABI". And I would prefer the break for qgpgme at least because of the mentioned problem not because I don't care about ABI stability but because I do and this is a big problem which only exists, because I didn't do it with the last repo move. There is no technical reason anymore for the abstract base classes.

Werner wrote:

We will bump the gpgme core version to 2.0 to indicate this split despite that there will be non-ABI/API incompatibility.

If the major version for QGpgME is bumped, shouldn't we at least remove the virtual base classes. Eg: delete FooJob and rename QGpgMEFooJob to FooJob. I did regret not doing this when i moved them out of libkleo since this architecture no longer makes sense in the standalone libnrary and technically the virtual bases make it nearly impossible to maintain ABI stability when adding functions. The reason for those was only because libkleo had that idea of different backends namely gpgme and chiasmus. But a Library called QGpgME should never provide another backend then GPGME IMO.
So no behavioural change at all, just something to make future ABI compat easier.

tested with Gpg4win-Beta-75++

Error on generate keys on card is now: "Failed to generate new card keys and a certificate: Wrong PIN"

This fix is also in VSD 3.3

This is included in test installers since some time already.

This change is also used for VSD 3.3

This works with gpg4win-beta-70.

I've checked and can confirm this is working as intended.

Alright, finally supported by gpgme (fot 1.24) For testing you may use

Solved for gnupg 2.2, 2.4 and 2.6. GPGME support still missing.

The new API isn't used anywhere. For now it can only be tested with the test runners. -> setting to resolved

This is also relevant for VSD 3.3. Backport is not needed, but gpg4win/VSD needs to include current gpgme.

I knew that we'd need something like D604 when I saw rM409e31458227, but then I forgot about it. :/

should be fixed with D604

with gpg4win-Beta-50: "Rückstellcode" is shown correctly with an ü

gpgme now checks for a SUCCESS status emitted by gpgtar when creating a signed and/or encrypted archive. If gpgtar is killed (or exits without emitting SUCCESS for some other reason) then the partially created archive is removed and Kleopatra reports a failure.

Status messages on successful creation of signed & encrypted archive

2024-09-18 15:21:33 gpgme[3250.d47]     _gpgme_io_read: check: [GNUPG:] PROGRESS gpgtar c 0 3<LF>
2024-09-18 15:21:33 gpgme[3250.d47]     _gpgme_io_read: check: [GNUPG:] PROGRESS gpgtar s 0 62 B<LF>

This ticket got superseded by T7262: gpgme: Move C++ bindings, Qt bindings and Python bindings to separate git repositories.

In T4060#190972, @werner wrote:

We need a way to pass --known-notation to gpgme_op_verify

We need a way to pass --known-notation to gpgme_op_verify

Fixed.

I can reproduce this: It works with setuptools 72.1.0 and it fails with setuptools 72.2.0.

Okay. Let us split it into different tarballs and repos. We will bump the gpgme core version to 2.0 to indicate this split despite that there will be non-ABI/API incompatibility. C++, Qt, Python will then go into separate projects. The old common List stuff will be kept in gpgme core for now. The gpgme core sticks with autoconf stuff but for C++ and Qt cmake style will be used instead.

Done. Unit tests verify the API. End-to-end testing will be done with T7234: Kleopatra: add disable/enable certificate in context menu. Hence, setting to Resolved.