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

Sorry I just noticed that I mixed up the duplicate closing. I wanted to close 7050 as a duplicate of this and not the other way around. Since this description was more general and better.

Just to triage this

Isnt this more of a task for werner? But if you could create a patch that would be great, too

this should be easy since we already start gpg-agent on start

needs to be fixed soon. But we don't have a tag for Gpg4win 5 or whatever we call a kf6 based gpg4win.

Thanks for the rort

I already mentioned the exact same thing in T7004 and this user also used the wiki style of the bug report form at first to report a bug. That is why I took the extraordinary step of blocking him.

Too similar to T7004 I have disabled this user.