I'd vote for the second (utf-8) which is more aligned with our other APIs.

Since CreateProcessW allows two ways for lpEnvironment (one is ANSI environment block, another is Unicode environment block), if we want to support these two ways for users' of gpgrt spawn API, we would offer either:

I'm talking about CreateProcessW and how a user of gpgrt spawn API can specify lpEnvironment (when needed).

Thank you. Applied.

The environment is a property of the C runtime and well defined as a block of concatenated C-strings terminated by a zero length C-string. In case of wmain the C-strings use wchar_t and not char.

Thank you for the bug report and your patch.

Please note that gpgrt_spawn_actions_set_envvars is W32 specific API in libgpg-error. Currently, the behavior with ASCII string is defined.
The patch is an answer in future if we want to extend the semantics supporting UTF-8.

String values are stored as UTF-16, but might not even contain a terminating doublezero since it can be any binary data. Note that on Windows the registry can be used to set environment variables. There "Edit binary data" shows exactly what is in the regkey. So if you use regedit with the String functions you can see that they are converted from latin1 to UTF-16.

The problem might be that we use getenv all over the place and don't specify the content. Frankly, it is not 100% clear to me whether the value of an enbvar need to be a string or can be arbitrary data sans nul? However, I can't remember that I ever wrote any code which did not assume ascii or utf8 for the value.

Here is my attempt:

Use of execve is better (avoiding use of environ).

Fixed in: rA69069bc63e6b: Remove an declaration for an unused function

In T7283#190941, @gniibe wrote:

I can replicate the problem.

The cause of this is that when it's comes with loopback mode, gpg-agent inquires back to the frontend and the buffer overwritten, which results parsing the line wrong.
I'm going to fix.

In T7283#190901, @werner wrote:

y38k problems with some frontends are known for some 32 bit platforms.

Please write a proper bug report and don't expect us to read a reddit thread.

I can replicate the problem.

Fixed.

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

y38k problems with some frontends are known for some 32 bit platforms.

As far as I know the practice to have separate -dev packages is very common among Linux distributions.

I wonder how common this practice of splitting development material into a separate file might be? It is in place at Alpine, since the file libgpg-error-dev exists. Once the related component is instaled, these messages/strings are printed:; output filtered:

checking for GPG Error - version >= 1.49... expr: warning: '^x-L': using '^' as the first character of a basic regular expression is not portable; it is ignored  yes (1.49)

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.

Thanks. Test works in my nightly builds now.

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".

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

That's my badness.
I noticed by the CI at https://gitlab.com/redhat-crypto/libgcrypt/libgcrypt-mirror

The changes broke saving of groups after editing. See T7181#190402 and T7181#190448. -> T7268: Kleopatra: Existing groups are not saved after editing them

Please remove the any configuration file changes from kwatchgnupg. That is not a good idea. Launching kwatchgnupg is
a debugging aid and not a regular operation and thus the user can also enable debugging selectively with kleopatra.
kwatchgnupg should listen on the standard socket socket:// - for Windows we don't yet need it because there we don't have sockets anyway. Or well, eventually we will have same but that requires work in watchgnupg and gpgrt for the logging stuff.

works in VS-Desktop-3.2.93.33-Beta

Thanks.

Did a quick manual test import and encryption/decryption with VS-Desktop-3.2.93.1-Beta with the relevant test-X509 certificate.
Works as expected.

While searching for a different issue I found T6512: keyboxd with data pipe in which as I understand it a keyboxd hang is fixed but the fix in that task is not part of the stable branch and only in master. I might be misunderstanding it but just from reading the comments in T6512 this might be related.

My suspiction with this is that here the exchange server / outlook parses the mail attachment into MAPI and somehow handles mails differently then other attachments. This automatic conversion regarding attached mails is why we always ask users in Support to send us a problematic mail as a file in a zip archive. Otherwise Exchange will convert an attached Outlook MAPI mail to MIME and on the receiving side we can no longer see the original strucutre. Similar things are probably happening on the receiving side where the MIME eml "file" is converted into a MAPIOBJECT holding the forwarded mail which then confuses our internal knowledge about the attachments causing this error.

Actually we should get rid of stdio functions and use the es_foo replacements from libgpg-error.

Still no news? :c @aheinecke

Backported for VSD 3.3

Backported for VSD 3.3

Needs to be backported for VSD 3.3

This has already been fixed by Tobias, but the fix needs to be backported (because this also happens in the branch VSD 3.3 is built from).

Backported for VSD 3.3

FWIW, I received that mail but I hope that this bug is at least fixed with today's fix for T7213. Thus not re-opening.

This patch has a new fix for T5793 which is now only used where needed.

I don't think that we can do much manual testing here because we have all test cases anyway in the regression test suite and our local non-public regression tests (which has the p12 files we are not allowed to publish)

Setting this to testing. Could be tested as described in https://dev.gnupg.org/T7188#188093 by verifying that the logged debug messages also use correct encoding.

I do not have Aarch64 machine at hand so what I did was building the package with changes on the build system with previous patches and checking the correct flag are in place (previously in RHEL10, but now in Fedora):

Do you have any way to test PAC/BTI on actual HW that support these extensions?

Alright. Done for master; backport will come soon.