Yes that probably gets lost along the way, where we communicate with scdaemon to generate the key. Needs to be tracked down. Such things can be very confusing to users. Especially if that increases the PIN Retry counter!

Yes I think that some keys must match, e.g. if you filter for S/MIME you only want to see groups where at least one S/MIME certificate is part of the group. Or for expired to see if there are groups with expired certificates in them.

Regarding https://invent.kde.org/pim/kleopatra/-/merge_requests/106 I cannot login to gitlab right now. Since I have to manually migrate my fdroid apps to the new phone and my 2fa app is one of them. But I agree with everything ingo said there.

• To configure a keyserver none I have now T6950: Kleopatra: Usability improvements for directory services configuration
• For tarball naming I created T6952: Gpg4win build system: Include commit hash in tarballs from gen-tarball.sh
• For the about dialog I have T6953: Kleopatra: show commit id in about dialog

I renamed the task accoringly.

Oh These are good points

This is not the first time I saw that users are confused by this. My wish would be to change the label of the Group at least to "S/MIME (X509) Directory Services"

@ebo Is this fixed now?

In T6946#181608, @werner wrote:

The min-rsa option was introduced due because the de-vs compliance allowed 2048 bit until the end of 2023 and we used a trick in our configuration file to switch that relaxed handling off with this year. I don't think that the --ciompliance option is really useful becuase it would also disallow ed25519.

A better option would be an --assert-algo option similar to the --assert-signer which we already have in gpg.

But thanks for reporting! I really like feature requests so please do not feel discouraged to request more features.

Sorry, but this is a "Wontfix" we do not support this by choice. We think that adding photos to certificates both gives a wrong sense like "I know that picture, iit must be this person" and also increases the sizes of the certificates a lot. It is in our opinion a misfeature in the OpnePGP specificationl.

Hi, ebo I would still think this is resolved. Because it was never meant that the user manually enters the value of "none" because there is no hint for the user that "none" is a reserved word. It should either be administratively configured which does not make much sense for Gpg4win or provided by the distribution. If left empty the default of GnuPG should be used. If we really want users to deactivate keyserver access by using "none" in the dirmngr.conf a much better solution would be a checkbox for this. In that case I would open a new issue.

In T4127#170518, @aheinecke wrote:

With the recent commit the old workaround works reliably again.

I can test this. For Ebo I want to try using the flatpack so that she can benefit from Dans work on debian stable, too.

I do not think this is a very common usecase. For me regarding CMS file operations it would be more important to implement T2435: gpgsm combined sign and encrypt which I find the most annyoing issue regarding CMS file encryption.

I think this is resolved now.

This is what T6799 this needs to be fixed in general.

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

The background for this is that .mime we can treat as as a custom extension for us since no one else that I know uses it but it is a registered extension.

Awesome, thanks for the report 👍

Since this is hard / impossible to test for, but the fix was obvious I am closing this directly. The fix for this is in GpgOL 2.5.12.

For the record. The code used to detect early on if the dark or bright icon theme should be loaded as a resource caused a crash during startup on at least Windows Server 2016 Enterprise. Our new fix avoids such API but I have created T6921: Kleopatra / Qt6: Improve accessibility detection for "Desert" high contrast scheme and fix it upstream to keep track of this since our fix is not fully complete in that it does not properly detect the Bright (Desert) High contrast mode and it should either be merged into KIconThemes or fixed in / with Qt6.

I did not relaize that when we originally implemented that feature we already exposed it through GPGME. So this has been fixed since 2020.

In T6900#180549, @andrewgdotcom wrote:

Hi, Andre.
...

Thanks for the explanation. To me this sounds very reasonable and I think that I am starting to better understand your use case in Hockeypuck.
Having a test example key + the intended revocation update would help at least me to dig into it a bit and see how this might conflict with RFC4880.

Hi,
so I talked to werner about this, and of course GnuPG accepts minimal revocations.
A revocation certificate. So that was my point. As he understood you, you wanted to revoke not the whole key but only a single user id but without the user id packet? Sorry I am not really the protocol expert. But for me a revoked key without any user ids sounds to me just like a "standard" revocation certificate revoking the whole key. And as said, that is well within the the Standard and accepted, and even used by GnuPG. E.g. in case of a keyrollover we attach such a minimal revocation certificate to WKD keys when we deliver key updates.

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?

Yes they can, the workaround, which GpgOL even suggests in the error message is that the mail may not be visible as plain text while changing flags or categories. This usually means that you have to select a different mail and then use right click on the mail you wish to mark for followup or add a category to. The whole problem is that while the plaintext is visible in Outlook we have to prevent changes to the mail from beeing synced to the server or otherwise it will also sync the plaintext.

From a technical standpoint I think the most minimal revocations which are technically possible should be accepted and thus I endorse the feature request.

Just to clarify, above ticket does not reflect my Opinion. It is a direct quote from a different ticket. It is my expert opinion that a combination of "Name <email> + Cryptographic Data" is not a personalised dataset since anyone can create it. But let us please not argue about that.

In T4393#180500, @andrewgdotcom wrote:

Perhaps we need to open a new issue for this, to keep the discussion more focused?

In T6891#180474, @ikloecker wrote:

I'm also wondering why syncing a handful of new messages takes so long. Or, actually, why syncing takes so long even if nothing at all changed on the server (the new messages were already shown by KMail). Maybe it's just the bad IMAP implementation of Exchange. Or maybe Akonadi has marked the folder as bad, so that it always syncs the entire folder.

@ebo told me that she can reproduce the problem by just moving around e.g. 1000 unread mails to a different folder and then e.g. marking them all as read while they are syncing. At least if I understood her correctly. @ebo could you please describe your test case?

Both the company and me are running debian dovecot.

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.

Your comment on speed might also be why I do not see this issue. Nearly all of my mails and all my large folders go through my private mail server that stands at a dedicated hoster. While our company mail server is located in the office and only reachable through the office internet connection with VPN afaik. I had a tool / command to deliberately slow down connections on some port maybe you can use something like that? I don't think that we can give you access to the company mail server / VPN since you are not a regular employee.

Oh yeah! I was looking for a way to Integrate LLMs / GPT Models into our code. Let us change gpgme_data_indentify so that it queries an online service about what to do with such a file 😅 I guess that is how Microsoft would implement such a feature nowadays. Gathering training data in the help of humanity.

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.

But I guess syncing a second client should do the trick to get the server state. At least ebo has afaik both claws and kmail configured with the same server.

No, our webinterface is telnet :)

The issue was obvious but I looked at the wrong place. I looked for a ref counting error but the issue was that the control only returned a temporary pointer that had exactly one reference.

If I understand you correctly we will then have the hirarchical keylist model, the flat keylist model and then as a new model the userid keylist model in libkleo/src/models/keylistmodel ? To be honest you probably know best how to implement this in the most useful way.

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.

Shouldn't that be the difference between SizeAdjustPolicy AdjustToContentsOnFirstShow and AdjustToContents?

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.

Gpgpass already installs a desktop file I just overlooked it.