Does alpine split the development files of libgpg-error into a separate *-devel (or similar) package like most other distros? If yes, then you need to install this development package.

Updates for projects' scripts related to GnuPG for building from source may be needed; So it is at least for libgcrypt; illustration (output filtered):

• https://github.com/C2SP/CCTV/tree/main/ML-KEM
• https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files

Thanks. Test works in my nightly builds now.

Backported for VSD 3.3

So we need a way to launch scdaemon via userv and make sure that the scdaemon user gives proper permissions to its socket file. gpg-agent also nees to check for a proper version of scdaemon and gpgme needs to be aware of this as well (if it want to directly connect to scdaemon).

Fixed together with T6864

Works fine.
For special DOS names only COM/LPT1-9 are supported names like COM12 are not handled.
But that is not really an issue as these names are always prepended with the temp-pathname and c:\tmp\COM12 are valid names.

The bug doesn't occur when the normal certification process is used because there we specifically tell gpg which user IDs to sign (excluding the revoked one).

The interactor log shows what's happening:

EditInteractor: 0 -> nextState( GET_LINE, keyedit.prompt ) -> 1
EditInteractor: action result "lsign"
EditInteractor: error now 0 (Erfolg)
EditInteractor: 1 -> nextState( GOT_IT,  ) -> 1
EditInteractor: no action executed
EditInteractor: error now 0 (Erfolg)

gpg asks what to do. Kleopatra answers "lsign".

Getestet, beim normalen wechseln taucht dieses Verhalten so nicht mehr auf. Aber einmalig nach Klick auf weiterleitung dafür neues Ticket T7276

For an additional quick test I forwarded a signed+encrypted mail from KMail as attachment, the mail containing the attachment was a) signed only, b) signed+encrypted.

Backported for VSD 3.3

T6512 is only for gnupg26. In gnupg24 we don't use fd-passing.