In T7627#200387, @werner wrote:

We won't apply any fixes to the cpp, QT, or Python language bindings in the 1.24 branch. The Qt branch has been factored out to the gpgmeqt project on request from the KDE folks. And yes, we should add projects (tags) for gpgmepp and gpgmeqt.

In T7620#200845, @Saturneric wrote:

I think it would be much better if GnuPG automatically performed a key listing immediately after key generation when a smartcard is involved. This would allow GnuPG to detect the presence of the subkey on the card right away, rather than leaving it marked as a stub until the user manually lists keys.

I see that you generated the secret encryption subkey with backup. This means that the secret subkey is generated on your computer, then copied to the card, and then deleted from your computer. The deletion is the reason why the subkey is marked as stub. Only after listing the keys on the card gpg notices that the secret key is actually on the card.

works for me, thanks

The first call of get_key receives the following key listing from gpg:

2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: sec:-:256:19:C4A24EB0B5F2E025:1746474606:::u:::s
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: cESCA:::D2760001240100000006180489130000::brainp
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: oolP256r1:23::0:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: fpr:::::::::DEC0948C398A6E7B50746EC6C4A24EB0B5F2
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: E025:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: grp:::::::::06BDACFBDEDBC5783A75AE5E7251FA3369C4
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 0FF4:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: uid:-::::1746474606::2222D8E2F373B9BDEE0DEA2A20A
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 9402214E9F984::Eric <eric@bktus.com>::::::::::0:
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: <LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ssb:-:256:19:EAFC5EA29B758B22:1746474606::::::a:
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ::D2760001240100000006180489130000::brainpoolP25
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 6r1:23:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: fpr:::::::::1AD596DDEC9B8CF3C1AC6C41EAFC5EA29B75
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 8B22:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: grp:::::::::52F0797C0B0439BBD718E2534D46656A6C45
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: 6A78:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ssb:-:256:18:A874804DB497B91C:1746474606::::::e:
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: ::#::brainpoolP256r1:23:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: fpr:::::::::33B273C7BD46E4EB63DD6874A874804DB497
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: B91C:<LF>
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: grp:::::::::34A1F8D9B2AA0CF07C2E042D70E10F9D4EBE
2025-05-05 21:50:23 gpgme[57059]     _gpgme_io_read: check: E734:<LF>

Note the line

ssb:-:256:18:A874804DB497B91C:1746474606::::::e:::#::brainpoolP256r1:23:<LF>

where the # marks the subkey as stub.

I have now identified the exact conditions and a reproducible path for the issue I previously reported. I will also attach the relevant gpgme.log.

I doubt that this is a gpgme problem. With a gpgme log we will be able see the exact commands send to gpg and replicate this on the command line.

Should be fixed.

For gpgme 2 we changed the data types of the time fields to unsigned: rMf2d40473b522e348d96a70c089d2191d0b978098 . Since this change breaks the ABI we use the above change for the 1.24 branch.

tested @ikloecker's patch succesful on amdahl.

The following patch for gpgme 1.24 should fix the test.

diff --git a/lang/cpp/src/key.cpp b/lang/cpp/src/key.cpp
index 42046aa..2b14d90 100644
--- a/src/key.cpp
+++ b/src/key.cpp
@@ -633,7 +633,7 @@ time_t Subkey::creationTime() const

I did a local change (on amdahl.d.o) changing _gpgme_subkey.expires to long long (ABI-break) and all tests succeeded.

It looks like the entirety of gpgme timestamping was missed when the 64bit time transition happened in Debian and Ubuntu.

This looks like a problem in gpgme. struct _gpgme_subkey stores the expiration date as long int expires which is a signed 32-bit value on all 32-bit architectures. gpgmepp casts this to time_t, but that doesn't help if the 32-bit value is already negative. The same problem exists with all other timestamps in gpgme (i.e. key creation date, signature expiration date, etc.).

The logs of gpgme would be helpful, i.e. run your test program with GPGME_DEBUG=8:$(pwd)/gpgme-$(date +"%Y-%m-%d-%H%M%S").log to create a log file with gpgme's logs.

This is resolved in the final Beta15.

I tried to apply crude patches. Since _POSIX_C_SOURCE is defined when <string.h> is included (in pre-compiled source I see

That error code is actually not an error code but it is the ERROR state from the Kleo SFM. We have seen that yesterday already.

this exact case is fixed in VS-Desktop-3.3.90.12-Beta
Adding further UIDs and making more certifications still works, too.

Very likely this bug exists since 2017 when support for promotion of local certifications to exportable certifications was added.

Fixed in gpgmepp for gpd5x. I think for VSD 3.3 we'll add a patch to gpg4win.

Attached is a patch which adds gpgme_subkey_set_flag() to handle both encryption and signing keys. Or maybe it would be better to add another signing function that does recpstring?

BTW, do we really need a C++ API for this? Might make sense due to the need for a context.

This was using GCC to build, but on AIX. I believe support for dollar signs in identifiers are platform specific.

GCC allows dollars in identifier, that's the reason why we haven't encountered this issue, I suppose.

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