Thanks for the report. This is the fun with different code pathes. Obviously the v5 fingerprint needs to be used for the pre-made revocation.

Push the change as rE4a9def77488f: estream: Fix call to string filter for estream-printf..

I see your point: allocating STRINGBUF to make sure nul-terminated string.
The code itself doesn't work well in a test case of tests/t-prinntf.c, because it assumes string filter should be called with NULL for string.

It doesn't actually work as expected on X11. There pinentry uses the NET::KeepAbove window flag to make the pinentry window stay on top of Kleopatra.

Like this:

@@ -1196,10 +1196,25 @@ pr_string (estream_printf_out_t outfnc, void *outfncarg,
    future, when breaking API/ABI is OK, we can change signature of
    gpgrt_string_filter_t to have another argument for precision.  */
   int allow_non_nul_string = (arg->precision >= 0);
+  char *stringbuf = NULL;

We could also pass a nul terminated copy to the filter function in pr_string.

All icons that are available in normal/light mode should now also be available in dark mode.

Thank you for the detailed report. I will look into it.

KF6 KWindowSystem has some convenience API to deal with this: https://invent.kde.org/frameworks/kwindowsystem/-/merge_requests/136

Awesome, thanks for the report 👍

Tested this some time ago.

Better don't remove your entire ~/.gnupg - removing the *.lock files after gpgconf -K all is sufficient.

And another note: In KF6 icon inverting happens automatically in ksvg or so, so that we don't need to ship breeze-dark anymore. And there will be a BreezeIcons library including the icons that can be used instead of the RCC file. This means we just need a quick fix for VSD and not a general solution for upstream.

One more data point: breeze-icons installs a copy of all breeze icons that do not exist in breeze-dark in the breeze-dark icons folder. So, with icon files on disk breeze-dark has all icons that breeze has even without using breeze as fallback icon theme. Looks like an oversight that the breeze-dark RCC generated by breeze-icons doesn't include missing breeze icons.

KIconTheme sets the fallback theme name to breeze, but those icons cannot be found because we only load the icon theme RCC for breeze-dark. I think we need to load both RCC files in dark mode. No, that doesn't work.

Possible reason: There's a kleopatra.svg in breeze-icons/icons, but there's none in breeze-icons/icons-dark.

This is due to the changed format of the VERSION file.

https://github.com/vorburger/vorburger.ch-Notes/blob/develop/security/gpg-hangs-on-hostname-change.md

Hope so too. If there was a docker image or something I would gladly test it, otherwise I'll report back as soon as a release is out

We can't test this but assume that the fix for T6752 is sufficient here.

This seemed to be related to T6831 but here we have the case of different keys and not just different subkeys.

I applied your patch and also fixed another possible problem.

Bug is in 2.2, too.

Fixed in rG591a53d716aa: gpg: Don't call keybox_compress when KEYDB_RESOURCE_FLAG_READONLY..

I found that the warning is emitted when it tries to call keybox_compress.
It should not be called when it's READONLY (which gpgv specifies).

i am not the original owner of this bug, but facing the same issue.

One use case that seems sensible to me is to try to convince a long-running operation (e.g. a sequence of key generations) to all use a single timestamp. In this scenario, there's no interest in setting the clock to be some variant of the current time, just an interest in it remaining fixed across all the operations.

Fix for i386 assembly pushed to master and 1.10 branch.

In T5709#180540, @bernhard wrote:

Would it be a workaround idea to double the attachments, so that the original ones would be used as reference for embedded viewing? And the other to be shown?

A user also report this problem with Microsoft365 and Outlook Versions 2302 and 2208. (Exchange is the latest online-Version.)

Would it be a workaround idea to double the attachments, so that the original ones would be used as reference for embedded viewing? And the other to be shown?

It looks that this is a bit more problematic case than I thought. Now building i386 with "-O2 -fsanitize=undefined" flags fails. I need to think little bit more how to handle this.

Assuming 4.1.0 means gpg4win - this version is too old. The user should update and re-open the bug with more details if it persists.

I'd say we should not do anything about this. Stale lock files are a general problem but can be solved using admin tasks. We may provide a tool to cleanup things on request.

Okay, now we have pass the warnings down to gpg and gpgsm so the problem will be easier to analyze. We also stop trying after 10 seconds. Sample error messages:

I have yet to reproduce this so I had not yet triaged this. The usual case to forward attached mail in Outlook is with .msg files but I recently noticed that Outlook on the web allows you to save mail also as .eml. Also .eml should in theory be much simpler to handle.

@jukivili Thanks a lot. Please push the change to 1.10 branch and master.

Attached patch should workaround the issue:

We were hoping before christmas. But it is unlikely due to some other stuff we had to do. Early Jan. Definitely a priority for us right now to get it out.

@werner Any news on when will 2.4.4 will land? I cannot figure out how to build the project from source, and I couldn't adapt the Fedora packaging to build it either. I would like to have a way to finally sign my git commits.

Thank you for your report.

I just rechecked we are actually not including the root certificate but we are including the intermediate certificate. Since there never were any complaints about this let us not change this. The original reporter must have somehow deleted the intermediate certificate or it was with an older certificate from us.

I do not think it could cause any harm, if a certificate is re-issued we can adapt and worst case we would ship a very small obsolete intermediate. And it would be just one less of a potential problem when verifying our signature that on this PC at the time the intermediate certificate is not available. Having a self contained chain in the signature is also helpful for scripted verification checks where you would then just need to check that the root CA is trusted and then can check everything offline.
And we take a bit of pride in the fact that we can easily be run on offline systems and there this might actually create a bit of a hassle to get the certificate in there. This would also allow for a more easy verification using osslsigncode itself independent of Microsoft tools.

I don't think that it is a good idea to include the chain. Sometimes certificates are re-issued - they are still valid but signed by another top level cert. The certificate also has the URL from where to fetch the intermediates. Let's close this.

Sorry for the fallout and thank you for taking care of it.

Ah... it fails by make check because it does change the text in tests/basic.c which requires update of hash value.
I'm going to take care of this regressions.

I am moving this back to WIP (my assignment to QA was wrong) since this is only done for me when the translations are accepted / commited in Kleopatra upstream so I can drop the patch.

Thank you. All applied and pushed to master.

In 2.4, a user need to specify disable-ccid in scdaemon.conf when scdaemon is built with integrated CCID driver (using libusb) but the user wants to use PC/SC driver instead.

A workaround seems to be to configure disable-ccid in scdaemon.conf.