maybe related is that the problems only occured when I had enabled draft encryption.

There seem to be two parts to this problem. One is the encryption side where gpgtar reports "file has grown" on large files and then the crash when Kleopatra decrypts.

Works. My initial tests also failed because on Windows 64 the registry value has to be placed in the WOW6432NODE

Apologies,.. I used ctags on read_w32_registry_string and that jumped me to build-aux/speedo/w32/g4wihelp.c which has a read_w32_registry_string that does not expand....
Now I found the w32-reg.c in common which looks completely fine.

Hi Werner, I need this for a potentional customer. And generally I need this in config, too. because in support we have to send customers configuration files which they do not need to edit and variables are important because of file system permissions. But most immedialtely I need this for homedir registry.

Yes. This is not a backend issue. Kleopatra can determine if it has connection to the keyserver but the issue is about that Kleopatra should determine that and indicate that.

Yeah, but cbiedl's issue is about something like that in Kleopatra for "users".

Ha! This would have affected Kleopatra if we followed werners suggestion to use default. But in Kleo I decided that I needed to show my users what the default is so we do not use default in this case.

I just talked with werner about that and he told me that GnuPG can return the fingerprint. And I also mentioned to him that kleopatra really assumes that a Fingerprint is always set for a valid key object.

I have allowed myself to edit this task to more reflect what this is about. Although the error is of course in my opinion more of a bug because it is so bad but I would rather fix it with this feature.

I actually agree that this makes sense. I mean at least Kleo could say: "Hey we have detected 50 files that are encryped in this folder tree, do you really want to decrypt them all?"

Should have linked the commit with a patch for Gpg4win here: 22bc52775bdb I mostly needed that as an immediate fix for someone testing with ldap servers a lot.

Last week:

Hi Ingo,

Searching the web "Why UAC is important" finds a lot of explanations https://www.digitalcitizen.life/uac-why-you-should-never-turn-it-off/

My suggestion would be to just keep using 3.1.14 But yeah there will be a 3.1.16 / 4 Beta soonish.

So I have talked with werner about this. The key-fpr is mostly required so that we can search for the public key belonging to the smarcard if we don't have it. This would also be something to do for the openpgp card.

Mmh, right I've used that but I still went with the key-fpr as I saw that and werner suggested this could be used by kleo. But it might be better to just ignore the key-fpr values which you have to explicitly query for PKCS#15 and just use

So, I've implemented a small widget and p15card class.

I'm currently working with Kleopatra and 2.3 and it works nicely.

Yes I agree it makes sense to have this as an explicit setting to cover both use cases.

Yes the other one was a duplicate, somehow my search didnt find this and I thought I had forgotten to open the issue.

This was changed in kleopatra some time ago to also generate keys with 2y expiry. So the motivation for this issue is gone.

Hi Ingo, If you run out of work you can do this next. Its already something that I'm showing during product presentations and a workflow I would like to recommend.

I noticed when testing the surprising behavior that when I changed the expiry on the primary key (tested with a smartcard) it did not change the explriy on the subkey. I think in the past it must have been different that the subkey did not get the expiry by default.

Thanks I talked to werner and agree that this is something to work on next. As we are pushing for more LDAP servers used internally which will use the common search and not the WKD discovery mechanisms.

This is a bit more complex for us. I have often noticed the pattern of Windows users that if something does not work as expected they click "Run as Administrator". When they do that once with our software our backend software gnupg is also started with elevated privileges, it might create lock files with elevated permissions it might create data files. For example a user then generates a new key, but already had some keys the public key will be placed in the existing keyring and the permissions will not be changed. But the new key files created will be created with elevated privileges. Then the user runs Kleopatra again as normal user and reports bugs because he cannot access his newly created key files.

Very strange. Both logs show no error.

Just drag and drop it into the input field. There is also a little cloud icon that makes this explicit.

Sorry, but we are a security software. If you give any application that you run on your system root privileges then that is not a secure behavior. This kind of stuff has been deprecated with Windows Vista. Yes we changed the error to a warning as it was too zealous. I agree. It is not our place to educate users. But users should change your operating procedures. You should not handle protection worthy data on a system without privilege seperation.

Mmh, all these issues should be fixed with the most recent versions.

Looks good to me, it no longer returns immediately with the error when there are no readers and the command itself seems to work. Thanks.

Yes, I think the service not active is the cause of the issue. But I don't really understand where this error is lost, I think this should be investigated because I would also expect it not to have a success on this line:
[3900] org.kde.pim.kleopatra: DeviceInfoWatcher::Worker::poll: context finished with Erfolg (code: 0, source: Quelle nicht angegeben)

Btw this only occurs for some options:

pinentry-timeout is indeed used when it is not set to 0.

In my opinion this is also a problem. Especially if you think about it for a while. The one minute timeout is too short and pinentry-timeout which I would expect here to be the config value to adjust this is not used.

When testing under Windows "scd devinfo --watch" returns immediately with ERR 100663614 Service is not running <SCD>
Probably also if you would use PC/SC on Linux but I have not tested this.