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.

@jmrexach I think I undestand now @TobiasFella can you have a look please?

Hi,
please use English in this tracker. At least using an online translation service.

Yes we could add that. Okular has this actually. For now we were Happy to go with the system default in the last version :)

I cannot reproduce this. If I right click the tab I can rename it just like every other tab. The tabs do not change their names based on the current filter that is used that is only their default name. And the default for the first Tab is "All Certificates"

Yes, basically these actions check if the underlying document is there and if not they make themself invisible. But then they should not be in the menu in the first place. But I believe the impact of this is rather low.

This seems to depend on the Platform theme. Under Windows I get the same results as you on linux It works fine with me

Mh, the problem is that this is really a speciality feature which KMail currently has, that you can configure for a contact to prefer S/MIME over OpenPGP even though you have both keys.

Talked to werner about this. We will but the list of signed files into the Gpg4win repo proper to that signing is part of the normal Gpg4win release (of course only if you have a signing key configured)'

Isn't the kleopatragroupsrc just such a config file?

Yeah I also signed all the binaries for the last Gpg4win release (4.2.0). I think we should support the case that only signed binaries are allowed on a system.

I have disabled update notifications for now. We can reenable them with the next Gpg4win release when we fix Kleopatra to again query for the Gpg4win version and not for the Kleopatra version. I am leaving this open to fix just that in Kleopatra. If you now go under help -> check for updates it won't show you an update anymore.

Will do. Thank you very much.

I give this low priority because in my view users should not initiate file encryption by launching Kleopatra. I still hope that most users should not even realize Kleopatra exists and only interact with it through the dialogs. Putting the action in the toolbar is also already possible through configure toolbars. I rather would find it more confusing to have two encryption buttons next to each other.

Giving this the same priority as the parent task.

Ah, sure that also makes total sense, I thought you wanted it disabled if it did not extend all subkeys.

You have to restart once. Then it goes away. We can't do much about this since we load the icons etc. at startup and don't have dynamic color changing. It might be better with the next Version which will update our UI Framework but no promises. I leave it open for now so that is a known issue.

Ikloeker is our resident accessibility expert and Kleopatra has a certificate for accessible software so I agree that we should not change it. Or is there a specific issue / condition for you that makes this extra hard to read?

I need to investigate why this happens. Maybe we can as a workaround fix it on our server side without the need for a new update.

If things start unexpectedly you already went to the console to change it or already changed it in the subkey view. Otherwise it is too intelligent for my tase since I have subkeys for example with different expiry dates. But nearly all users won't have that. I think the current solution is good. But @ikloecker can you change it please to +/-1 one hour you are right that the time window is too short.

@TobiasFella Since werner, ebo and ingo will be only talking about the smartcard related issues next week, I think there are plenty of nice jobs here :)

Feel free to fix this

I think the attack ingo talks about would mostly be covered by checking if the file already exists before moving it into the private directory.

In E1020 @TobiasFella wrote about this: Sizehint is correct, but only at a later point in time; also, apparently some cache invalidation problem? Since the current version works fine with a fixed size, might not be worth the effort to fix.

I think this currently is fine. You can always go into the subkey view and the the expiry date there for corner cases.

I think we can close this issue. Ikloecker explained why. The hint comes from the help files and I think at the time I opened the issue I did not use the help messages.

Hi, you have "compliance de-vs" in your %APPDATA%\gnupg\gpg.conf. But have installed Gpg4win. The default key pair algorithm of Gpg4win is not VS-NfD compliant, in fact the whole Gpg4win version was not approved for VS-NfD. So just remove that compliance line from your config and everything should be fine. Otherwise the forbidden indicates that you are trying to generate a non-compliant key with a version configured for compliant operation.

I don't think that we need to show which keys are compliant or not because that is already shown by the VS-NfD compliance status. And then we only have left the case where the keys are expired / revoked so a user could sort by validity to find out which ones are those.