Since this is a bugfix and it was related to 6742 with some commits having overlap i decided to also pick this for the 32 release branch.

Discussed this with ebo. This is a bugfix that should be in the release even though it is multiple changes I will cherry pick them over to the release branches.

Thanks for the reviews. And your beautiful work, by which I also mean the response to the feedback and how you managed to work with phabricator. I will commit the patch on your behalf then later.

Well in Gpg4win it actually works better :) At least there the configuration files are all in one place (or mostly, or should be). Anyway a difficult issue which I am only planning to touch when we do the migration to Qt6 since this is heavily Qt releated. But the current plan (which might change) is to do that for the GnuPG VSD summer release which will be the next feature release after 3.2.

We discussed this at length again. I would not veto a change that would allow users to encrypt to expired S/MIME certificates but the main use case I had in mind here was with regards to "Some error" happening when encrypting ( like T6545 T6398 ) . So that in the keyresolver everything is green but you cannot encrypt. Or that you have an incomplete certificate chain or an untrusted root certificate and it will take your administration some weeks to mark that as trusted. That makes this feature a bit hard to test so ebo mostly tested with expired certificates. (And I know that technically you can't verify if a cert is expired or not if you have an incomplete chain). A better test will be with a fully valid cert that has an unreachable CRL distribution point. I have such a cert and will give it to ebo. So she can test again and if that works as intended -> Key resolver green -> Error -> Allow to encrypt anyway but not vs-nfd compliant. I think we can set this issue to resolved.
The whole question regarding expired / non expired is a different topic on which, as I said, I changed my mind. You can easily explain to users "You cannot encrypt to expired certificates" but you cannot easily explain "you cannot encrypt to support@greenbone.com because they have unsupported cert extensions in their certitifcate"

So as a replacement for what we have in Kleopatra this would work.

To be honest. While I get that the customer wishes for even more non standard behavior and I somewhat agree in the case of smime that it makes more sense to encrypt to an expired key.

Well I guess T6805 is now the followup ticket that I did not create when I just closed this issue as Wontfix. Ingo can you take T6805 and do what you wrote in your last message here?

This is an incarnation of T6685 while we decided to deprecate that job we did not open a ticket to do it and forgot about it. So we did not notice that it was still used in the keyapprovaldialog. Fix is to replace it there with the correct key generation job.

Thanks, I will test this and if it works as expected I would also put it in 2.2. since it was pointed out to me from a customer at our approval institution and I think they will be glad if they see that this is gone in the next release and I don't see any regression risk associated with that change.

To be honest, the only backup worthy settings file of kleopatra is the kleopatragroupsrc right now. Most other settings are pretty much only for convenience I would not even bother to back them up. When something important is configured by the administration that should go through the registry. As we recently noticed, through talking to people at froscon and with the BSI the most common case was that our kleopatra settings were actually never updated or only saved by accident.

Well the icons are there. So I don't think this needs more QA.

This will definitely not be changed for 3.2 it will be a very invasive patch with a big regression risk and which does not make real sense to do before we switch to Qt6 since it involves patching Qt.

When I created the GnuPG VS-Desktop MSI Package I messed up and forgot about a file that Gpg4win writes where to place the config files.

Tested both on Windows and Linux and it works now.

I think this works as intended.

So I just checked how Outlook does this. It saves its temporary files not into temp but into:

C:\Users\Andre Heinecke\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\PK5RYJME

(Last part is only random) Now the fun part is that when you close outlook, it just closes the Windows in which the files are open. In your case it would close the image viewer and then deletes the file. The files are write protected so there is no real data loss. So for a high security mail client that might not be the worst behavior. Maybe we should do it like this, too: https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-ifileisinuse-closefile I mean we want to be an Outlook plugin so why not do the same?

Yeah there were some logic errors with this but I think I caught them all.

Since 23.08.2 the crash is gone again as expected. Thanks. Btw. do you know which was the first version that had this crash? I am a bit worried that our fellow debian stable users in the office might be affected with the next debian upgrade. Since we use signed / encrypted mails a lot. :)

This works very well. I would like to add some data though about the number of reduced syscalls before resolving this.

So with my ryzen 9 on tumbleweed:

So priority Normal for "have a way to show html in QTextBrowser" and after that move it to prio low. Our SecOps explicitly state that HTML mails should be avoided.

For now I am for the KMail approach with QTextDocument. So if we have multipart/alternative show a button that HTML is available and then the user can decide (e.g. if the mail is validly signed) to render the HTML part in QTextDocument. This might give us also an idea how well this works overall. And then let us wait for now until we get to the real GpgOL.js use case. For the customer we talked today is a bit special in that he mostly wants to have a way to view decrypted mails in Outlook. That is something we do not want to compete with.

Changing the prio to normal as we have this now and want to improve on it.

So I tested upgrading from 3.1.26.0 to the current beta and it also did not work.

I want to have this for the next release since I want to use that mechanism for the promised "Tender version of Kleopatra". This will mean that we replace the "VERSION" file with a QSettings ini file where we can easily add more meta information as we like.

While I want to investigate the syntax error in URI since I don't think the testkolabs have a syntax error in their URI the behavior you are describing is completely correct in my understanding:

For a very long time i would have agreed with you. But i now understand the usecase. You misunderstand that feature just like i had. It is not about checksum verification or checking. It is for detecting changes in folder trees so that you know when to reencrypt and update your encrypted archive of that tree. Yes this could be done somewhere else but the usecase is valid for kleopatra.

Ah i und erstand what you mean now. Btw while checking this i found it confusing when i opened the incidenceeditor on an event in somone elses calendar. It did not show the correct organizer or even attendees. But this indeed might be caldav related. I would like to give you access to our radicale instance but i think it is in our VPN and so only the actual employees may access it (not even ingo)

In T6776#177536, @dvratil wrote:

Makes total sense, but I'd like to think about a more general approach if possible - what e.g. Google or Outlook do when you add someone else's shared calendar is they don't send you invite for their events either. But it's not because they wouldn't notify you about events where you are not an organizer, because in many cases you are just an attendee of someone else's meeting in your own calendar and you definitely want to get reminders for those.

Nah, forget it in that case. I might report a bug to SUSE in that case but we should not invest in fixing such things. I was planning to either use a self compiled PIM stack or Flatpack anyway.

Thanks for creating the task.

Looking at sign_file I can see several places though where it does goto leave before gcry_md_open is called on md. So the fix seems obvious to initalize md to NULL so that the gcry_md_close in the leave part does not work on an uninitialized variable.

gpg (GnuPG) 2.4.4-beta56
libgcrypt 1.11.0
gpg -z0 --yes --batch -esu ldata-test -r ldata-test 10gb-random.dat > 10gb.gp 13,37s user 22,54s system 95% cpu 37,421 total

Please excuse my question but this issue has been WIP for 8 months. I think it was forgotten a bit. Especially since we are not shipping Okular for general signing of PDF documents this issue might help as a stopgap for Smartcards which we do not yet support natively and reduce the pressure a bit to add more PKCS#15 smartcards which can currently be used with Adobe and Mozilla NSS through their proprietary PKCS#11 modules. So I would like to raise the priority for this a bit. But I don't think high is appropriate. That would be for werner to decide.

If you tested it yourself I would say this is enough to move such a task to resolved. If someone else should test it you should remove yourself as the assignee. I will test this by comparing 2.4 performance to master. We need to clean up the WIP tasks in our workboard.

Hello,
this is a support question since you are not a customer to my knowlege please use https://www.gpg4win.org/community.html

In T6775#177408, @werner wrote:

Are you sure this is from a regular Outlook installation and not the common web based outlook? Please enable GpgOL logging and share the log with us. Do not use production keys or messages.

There should not be an exception "Invalid crypto engine" in that call. I expect that gnupg errors out immediately if the parameter with tofu is given while instead it should print a warning and show no information. Or of it errors then Invalid Crypto Engine is definitely the wrong error for that.

I got an idea. Since the gnupg manual is part of that submenu I will include the gnupg manual in Gpg4win. Not sure yet what to do about Linux since we don't have the manual there as PDF. Maybe just an online link to the GnuPG documentation in that case.

Sorry took a while to download all the debug info. Maybe we have different libical versions and this is a libical issue.