I just noticed this because it was accidentally assigned to me and WIP. Since you already mention it in T6325 I would close this as a duplicate of T6325 because at least they can be tested together and testing is the only thing left here that it works with the next 2.2 version.

I have another one, a bit hard to report upstream since it is related to the event and that contains personal information. So I will forward you the event in question privately. It is an ics file attached to a mail, I select "open with Korganizer" and when I hit "merge into existing calendar" it crashes with the debug output:

This works now. Tested both decrypt and encrypt. Sadly just one commit after GPGME 1.23.0 but this was a miscommunication because I was a bit unavailable :( But we can patch this into our installer.

You are right, this is a new feature that could be useful but is now in high demand and not a bug so Wishlist is more appropiate.

IMO for LDAP we should not warn at all. Because there it is possible to remove certificates.

In T6637#176910, @fse wrote:

OK, fine, however, in order to be able keep an overview of our tasks I would still keep track of them in our GitHub, where I can create a sub-issue from the list of tasks with one click. But we will post our comments and results here as well as far relevant for the purpose of documentation. I think most of the points Jussi raised are more or less clear to me anyway.

I opened T6771 for this because this issue is done.

In T6766#177137, @ikloecker wrote:

I haven't added the possibility to start a group certification directly from the confirmation message.

That output was also misleading,. that was from before I added the ignore-crl-extension in there. I was confused because I still got the error:

So dirmngr already has that option.

I think this was fixed with the fix for https://dev.gnupg.org/T6534

I mean this would also be solved if we did not use qiodevicedataprovider but pass the filenames directly to gpg for single files, too. (can't remember the ticket number) but I don't want to do that right now.

In T6526#177082, @ikloecker wrote:

The original issue was about creating an encrypted archive. This code doesn't use Qt anymore for writing the result file, but delegates this to gpgtar.

That sounds like a solid conclusion. I mean if errno is not set explicitly it is basically undefined which value it is, so maybe some other function set errno to no space left on device in that one case where it "worked".

Fix was trivial, the classical cancel is not an error problem in the QGpgMEChangeExpiryJob

This has sparked my curiosity.

This happens when cancelling the password entry on normal keys, too. The strange thing is, the changeexpirycommand already checks if "err.isCancelled" and should do nothing in that case.

Tested and there are no available actions. Works.

Ok then we can resolve this. Because I don't want to change the code there too much since it is about a plaintext leak which we cannot reliably reproduce so any change there we cannot really test if it brings up the plaintext leak again. And for users that have problems with the changing of the mail we can point them to the workaround.

Mh, let us concentrate in here on error messages. I was thinking "but what about disable-dirmngr in the settings" then all publish / refresh / receive actions should be disabled or invisible. So that is better something for a different task.

This issue might be a bit to general, some things like avoiding bad error messages are more important then a fully nice solution. A nice solution IMO would make all the "publish on keyserver" actions / checkboxes invisible in that case. If a restart is required when the setting changes that is ok in my book because the way we use "none" is intended that our entry level packages have "none" defined in the global config. Of course if a user then manually enters a value when none is set we would also need to bring up a message box stating that a restart is required for the change to take effect.

I tend to give this high priority since our SecOps state that the creation of non vs-nfd compliant keys is inhibited by our software by default (at least in the UI) I mean no one complained and it is not a regression but this should be fixed soonish. But this does not neccessarily mean before the next release.

Yes, it consists of libkleo DocAction actions which are invisible unless they find the document which they would open. I expect that I can somehow find the menu element and then hide it. But a patch against KXMLGui to hide empty submenus automatically might be a better use of our time. So I put this in the backlog and if someone wants to pick it up in some downtime feel free to fix this :)

The installation parameter for this is documented in our installation instructions. What is new with the next version is that for all files when you open them after installation of GnuPG VS-Desktop for the very first time you will be asked if Kleopatra should be used and have the option to make this permanent.

Since @ebo did not really know how to test I just checked that it is passed to gpg to resolve this issue.

Ah nevermind missing icons were related because I also removed the highcolor icons for testing.

Mmh, on further checking I notice that some icons are missing though. Need to investigate where they went. I basically just took the inst-breeze.nsi file, and removed all the NSIS things and did a sort -u on it to create the list of icons.

So, I smashed this all together. The icon subset and the cross compile patch, and my time for first startup was 5 seconds then once with procmon enabled 7 seconds and now with a reduced set of icons I am down to Kleopatra to 1.7seconds. The icon subset is just 1.4mb. With all the icons we would have installed for Okular and Kleopatra. I don't have enough time to clean this up today to push it but this looks very good.
Although I am thinking to add a way to kicontheme maybe as a global variable to provide the name for the resource file so that we can properly switch between breeze-dark and breeze.

Ok. Both notepad and file encryption now again produce errors as expected. So the new override would just be a new feature and no longer a regression.

And yes in gpgsm.conf both the extensions are also marked with ignore-cert-extension.

While remembering this I added to our standard.conf (and for testing first to my local conf):

For testing with file encryption and notepad you can use this chain which is valid but does not provide a valid CRL for us

We just realized that similar to what we had in GpgOL ( https://dev.gnupg.org/T6701 ) that AlwaysTrust is used by default. And this will now result in the behavior which I also mentioned in our meeting that without question it encrypts to any S/MIME certificate. Without any warning that it is not VS-NfD compliant to do so.
This must be fixed because otherwise we show an operation as VS-NfD compliant, e.g. to encrypt to a certificate with a broken CRL. Which is not VS-NfD compliant because the CRL check was not done.

Since I tested this both with valid and invalid filenames on linux and on windows I set this to resolved.

The URL was just wrong for Windows. I added debug output and the results are different:

Yes and I get the same result with PNG files. But calling shell execute with such an url looks strange to me, I will try QUrl::fromLocalFile as we use in Kleopatra.

Moving the definition and changing it to the name of the po file worked.

Pretty sure its the translation domain. Thanks! Will try to fix that tomorrow

According to werner the gnupg tools use GetCommandLineW even when they are not build with -municode.
So a solution could be to build gpgme-w32-spawn with -municode and start the child process with CreateProcessW, this would also solve the problem that GnuPG could itself be installed into Paths which are not representable in the local 8 bit encoding.

I think that if we know that GnuPG is not encrypting to expired keys we need to use the X icon for that key and disable the sign/encrypt button until this key is removed.

So I think we need to somehow show this. This gives users the option not to encrypt to the one or two expired keys and maybe ask them from updated keys or continue the operation anyway. (Although I am unsure if gpg would not throw an error in that case even with trust model always). From a User Experience standpoint I think we need to make it visible that you had a key for a person once but that this key is expired now. Regardless of wether or not it should then still be used. The "No Key" is a bit of a wrong information here. So show such keys as the first entries and then disable the ok button until the user somehow solves the issue.

Sorting problematic keys to the front make sense to me, but might be complex since we just add the certificatelineedits and then would need to do some kind of dynamic layouting regarding on the return value of the linedits key.

Yes, the wording for this line should be improved, I agree.
In the current release and the releases up to now this action did not work at all when it was not used in combination with encrypt. That usually happens only if an administrator activates the "always_sign" option, prefers S/MIME and then does not issue users with S/MIME certificates. For OpenPGP we have the "Generate" option preselected in that case.

For sent mails folder there is no solution. The problem is that if the mail never leaves the exchange server it is not converted to a standard compliant PGP/MIME but left in Microsofts internal MAPI format where it looks like this. I think thunderbird has support to fixup a message if the mimetype of the first attachment application/pgp-encrypted. Which reminds me that we need to change the filename of our internal attachment, too to use .mim as an extension. Then you will at least also be able to open such messages on other clients with Kleopatra directly to view the contents of the mail. And a side effect of this might be that Enigmail might then be able to open the mails. If not we would need to talk to enigmail how to solve this.

So I have analyzed the problem and I think I understand it now, but I don't really have a solution yet as I think a new option or change in gpgtar might be needed. I think the easiest would be that if --utf8-strings is provided that also the --output parameter is assumed to be UTF8 encoded? And not just the files from --files-from?

Sorry, done now

This one is one me. I think the issue is gpgme-w32 spawn.

Under Kleopatra -> Settings -> Configure Kleopatra -> GnuPG System -> In the Tab Secret Keys -> Is there either "Delete unused Passwords after N Seconds or Delete Passwords after N Seconds set to zero or the option "Do not use the password cache for signing" set? In this case this would be normal and expected behavior because it turns of the caching.

Aha, so you know how to provoke us into action, good man ;-) Alright I give it high priority. No seriously, makes sense to have we'll see when we can fit it in. Needs an extension in our internal api so probably not in the next release but sooner rather then later.

Mmh or even select all expired keys and then refresh them.

Multi select makes this nontrivial. But I think only with multi select this would really be useful. But yes it is a nice item for the backlog. E.g. if you know that a company switched their mail domain you might want to refresh all the keys from that company and you could do that with filter + multi select and refresh.

This can be resolved I tested this myself and gave a beta to the affected customer which also worked for them

Eva can you please try to reproduce this? I can't really imagine that this is true since we have soooo many users with yubikeys and do a lot of internal testing on them. To be fair please try with your standard devuan GnuPG and not just with an up to date version.

Yes I can see that gpgtar correcly lists the directory with procmon, accesses the files but fails to create the output file indeed.