Mh, no, on the other hand the style is useful in the "All certificates view" to make distinctions based on multiple parameters. "Like trusted S/MIME root certificate" and it is useful to see that right away instead of using the filters. So my vote would be to clean it up, but keep it in general.

Hard to decide as we have no data how much it is used. :-/ But I tend to agree here. We should not loose sight of the fact that Kleopatra should be more of a diagnostic tool and provide all the information a user might need to solve their issues with signing, verification, encryption and decryption. Kleopatra is not something a user uses so often that they play around with appearance or so like they maybe would in a MUA. Certificate management is just an unwelcome side effect required for crypto. But users do not want to do certificate management for its own sake.

In T7212#188683, @ebo wrote:

We might also consider going all out and allowing a configurable appearance on a per certificate level. Then this feature would see an increase in use for sure. But it should work without issues, in that case, as then people will notice them…

Uhm this is a task I have with High priority. I do not know what to do here or what it is really about. -> Invalid.

Yes, this is all something that is ugly. The VS-NfD colorization was done by justus winter back then since I fell sick and it was one of his first and only tasks in Kleopatra. So it is normal I think if that is implemented differently then other things. And in general the whole appearence configuration is I think rarely used. To me it always felt like a "We add it because we can." feature. But also with this mix of filters defined in a preinstalled libkleopatrarc and additionally hardcoded filters it is all strange.
Well colors and so on should be changeable for accessibility of course.

Wouldn't this usecase be better solved if we could highlight trusted-keys in the keylist better? I mean not trusted-keys as in "this key has full trust" but this key is one of 1-10 (In real life the most we saw was 5) which is configured as a TrustedKey

TrustedKey1
The value specifies a fixed trust root (trusted-key). If more than one trust root is required, the entries TrustedKey2, TrustedKey3, TrustedKey4, TrustedKey5 may also be used. Take care to specify the 40 hex-digit fingerprint of those trusted keys.

The problem here is that Kleopatra could do that of course, e.g. after importing a file. But this has to be done by the GnuPG system to handle all the automatic cases etc.
I leave this up for triage, since I am not sure if this is a bug, or a feature request. @ebo I believe you said to me that you tested this with keyboxd? As my answer would have been that keyboxd would be required for a proper solution to this.

I think we can close this as Wontfix since it is our opinion to wont fix this issue. If there should be more prevetion of accidents it would probably be better to have the user type in "DELETE" or "YES". Anything else then another click confirming a popup. Since this will just be clicked away through muscle memory. This came up again in T7211: Kleopatra: configuration option to prohibit deletion of certificate with secret key

In MMO Games this is usually handled that a player either has to type in "DELETE" or type in the Characters name to delete the character. At least in the last games I played.

KWin has a script called "Dim screen for Administrator Mode" which mimics the windows behavior.

I would give this low priority. There is no way to prohibit that except if the user has no deletion rights on the file system. There are already multiple dialogs asking the user to confirm the secret key deletion. A user could by the same logic "Free up some space" in their local home directory and delete %APPDATA%.

Yes this was just a performance thing and had no other UX reasons so we can change it.

Ok, well in the days were did not have that much development power on Kleopatra and GpgME refresh keys just took the lazy part and offered the gpg output in a window. I still think that can be useful (e.g. diagnostics) to have as an additional details button. Especially in case of errors. What very often happens here is that the online access gets blocked somehow maybe even only to some servers. I am not sure if the numbers are really a helpful information. Please keep in mind: What do we want to inform the user about? If the user just sees some numbers is this really helpful? I think the user might want to either see which certificates were updated and which werent or if there were any problems updating. Personally I would find the information "what" changed the most important but that seems to me like too much icing on the cake. Like

• Changed expiry: foo@bar.baz <0xbadbeef> boo@bar.baz <0xa....>
• New signatures:

....

• Changed subkeys:

....

we are doing this for the last releases. The list of files can also be found in the repo now in gpg4win.mk.in

Will this be backported? Since the pgpcardwidget otherwise contains strings which are neither in master nor in kf5 I would say so.

I and most users don't read what software says and just click where I think I reach my goal fastest. If there are only instructions to do something I am unable to continue.

No I don't think we should support that. I just meant that at first start we have to expect that the user does not have a secret key yet. And offer an easy way out of this by generating one.

Yes sounds good to me. Since we have the ability even in the full list view to filter for "only with secret" certificates. Regarding gpgme_set_sender. Only GpgOL uses this, we only really need it for TOFU I think. To leave that discussion / point out of this issue I created T7199: KMail / Kleopatra: Use gpgme_set_sender to add a hint which UserID was selected for a signature

Yeah this task is a bit bad as it does not really split this up into actionable tasks. But I found it obviously "ugly" (Since QWizards are ugly) and from a user experience standpoint outdated that I thought a general task would be enough to say that this must be changed and improved. The first start is the most important one and to be greeted by a wizard which I still am apparently where I don't really understand what the software wants from me is strange.

For me each time wine is upgraded I get for the first time an error when building something, but it is not slow anymore. Is this resolved?

No next work item here. So resolved.

As there does not seem to be a problem here anymore -> Resolved.

I don't think this ticket is up to date. Especially since we now have more components. Auto update or Microsoft Store integration would be much more important then a single click installer.

This is fixed

So Tobias fixed the technical reason why there was no import tab shown after the certify questions because I was too lazy (no I had no more time ;-) ) when I implemented this to carry the keylistcontroller around.

I've talked to ebo about this and yes she will create subtasks for at least GPGME log an qDebug logging the GnuPG Logs can already disabled in the config so we dont really need it. Currently it looks like this and I find it rather confusing:

The unexpected behavior of the MAPI store needs to be tested and handled. I had indeed forgotten about POP Mail in my concerns not to leak decrypted mails back to storage.

Resolved and customer confirmed this

No, if you then find out that you cant reach anyone in the protocol you should be able to get back.

In T6813#184976, @ebo wrote:

Works on Gpg4win 4.3.1, too.

But noticed an inconsistency for the key creation via GpgOL: Contrary to the behavior for key creation in Kleopatra in Gpg4win, you are asked for a password for the new key.

For VSD I somewhat agree since this is the difference between a VD Compliant signature. For the community edition though level 2 is usually enough and should also be indicated as trustworthy. So I am currently in two minds about this.

In T7064#184630, @TobiasFella wrote:

Can you clarify on what the show parameter is intended to do? I don't yet see how it would be useful, as the distinction between VSD and gpg4win is already made by whether the respective file is present or not

Since we can have multiple servers for S/MIME it could be nice in the search results to sow from which server the reply came. But I think that is out of scope or better a different issue since the current API does not provide that info.

Tobias can you add this please and extend libkleos DocAction so that it handles a web URL as an alternative to a file?. And takes an optional additional paramter for "show" which then depends not on weather or not the file exists but on something like "is_vsd()"

Thanks. I wonder if we should inform distros about this?

FYI as a VSD customer you have access to support. Please check Help-> about Kleopatra for the infos,

Btw compare the Kleopatra versions in Gpg4win and your VSD Version. They should mostly be identical with VSD maybe lagging a bit behind, Or your emplayer has not updated VSD. Many don't

This is fixed on RNPs side: https://github.com/rnpgp/rnp/issues/2198

Btw we should probably add TB in our QA environment to check for such things. Esp. with future changes in GnuPG we should try to use TB and maybe a bounycastle MUA (Greernshield?) to avoid creating accidental incompatibilities.

I cannot think of any of our products where you cannot chose the signing key.

To reproduce:

• Send a mail to yourself
• add an attachment
• select encrypt

I think last time we talked about some generic solution for this. And ended up trying to research if we could add this in the end after linking is done to avoid having to patch/add an RC file for every library like GnuPG. Kleopatra and GpgOL already has one as you can see in windows with right click / properties and then details. Maybe we need to change the values there.

I agree with the column save /restore but i disagree with adjust to contents since this can create a "jumpy" layout e.g. with long comments and the user might be annoyed if she changed thr layout and it is then automatically changed again