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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Tue, Apr 23
Tue, Apr 23
Wed, Apr 17
Wed, Apr 17
• ebo moved T6827: GpgOL: Check S/MIME draft encrypt and use GPGME_ENCRYPT_ALWAYS_TRUST from QA to vsd-3.2.0 on the vsd32 board.
Thu, Apr 11
Thu, Apr 11
• ebo moved T6813: GpgOL: Key generation window does not close from Restricted Project Column to Restricted Project Column on the Restricted Project board.
Works on Gpg4win 4.3.1, too.
Tue, Apr 9
Tue, Apr 9
Yellow indicates a warning. In the old days we used yellow in too many cases and people barely got a green. This raised more user questioned than it was helpful. There is also a problem with accessibility if we overload colors too much.
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.
aheinecke lowered the priority of T7079: GpgOL: Mark level 2 and 3 in a clearly different way from High to Normal.
Wed, Apr 3
Wed, Apr 3
With Gpg4win-4.3.1 I consider this solved:
Wed, Mar 27
Wed, Mar 27
We're waiting for a RNP v0.17.1 release which intends to tolerate this mode.
https://github.com/rnpgp/rnp/issues/2198
https://github.com/rnpgp/rnp/pull/2190
This is fixed on RNPs side: https://github.com/rnpgp/rnp/issues/2198
aheinecke added projects to T7061: KMail/GpgOL: Incompatibility with RNP: KMail, Restricted Project, gpgol.
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.
Mar 4 2024
Mar 4 2024
Feb 21 2024
Feb 21 2024
• werner lowered the priority of T4553: Compatibilty with encrypted mails sent to SecurePIM from High to Normal.
Feb 15 2024
Feb 15 2024
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)'
Feb 14 2024
Feb 14 2024
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 guess that's what it is called. A person in the forum told that GpgOL could not be loaded in Outlook and saw that the signature is missing in the new version. But it was there in version 4.2.0. With the command Get-AuthenticodeSignature I could confirm that this is the case.
Feb 9 2024
Feb 9 2024
A workaround which (currently) works for flagging and categories both is:
Feb 8 2024
Feb 8 2024
aheinecke closed T6827: GpgOL: Check S/MIME draft encrypt and use GPGME_ENCRYPT_ALWAYS_TRUST as Resolved.
Jan 30 2024
Jan 30 2024
That is an old bug report with a couple of fixes introduced over the years. As of now we sometimes see hangs on Windows on our test VMs. The common cause here seems to be USB card reader issues. Let's close this bug and wait for another bug report with current software versions.
Jan 24 2024
Jan 24 2024
• werner moved T6559: GPGSM: "always trust like override" or "force" option from QA to gnupg-2.4.4 on the gnupg24 board.
Jan 24 2024, 11:37 AM · gnupg24 (gnupg-2.4.4), gpgme (gpgme 1.23.x), gnupg22 (gnupg-2.2.42), Feature Request, gpgol, S/MIME, kleopatra, Restricted Project
Jan 15 2024
Jan 15 2024
aheinecke raised the priority of T4127: GpgOL: Setting category or flagging crypto mails is not possible from Normal to High.
In T4127#170518, @aheinecke wrote:With the recent commit the old workaround works reliably again.
aheinecke triaged T6865: Email will be sent encrypted after draft was saved in encrypted state although encryption is disabled as Normal priority.
Thank you for the detailed report. I will look into it.
Jan 8 2024
Jan 8 2024
Since this is hard / impossible to test for, but the fix was obvious I am closing this directly. The fix for this is in GpgOL 2.5.12.
Jan 4 2024
Jan 4 2024
Jan 2 2024
Jan 2 2024
• werner edited projects for T6865: Email will be sent encrypted after draft was saved in encrypted state although encryption is disabled, added: gpgol; removed Too Old.
Dec 19 2023
Dec 19 2023
aheinecke added a comment to T4127: GpgOL: Setting category or flagging crypto mails is not possible.
Yes they can, the workaround, which GpgOL even suggests in the error message is that the mail may not be visible as plain text while changing flags or categories. This usually means that you have to select a different mail and then use right click on the mail you wish to mark for followup or add a category to. The whole problem is that while the plaintext is visible in Outlook we have to prevent changes to the mail from beeing synced to the server or otherwise it will also sync the plaintext.
bernhard added a comment to T4127: GpgOL: Setting category or flagging crypto mails is not possible.
A user also report this problem with Microsoft365 and Outlook Versions 2302 and 2208. (Exchange is the latest online-Version.
Assuming current Gpg4win v4.2.0)
Dec 18 2023
Dec 18 2023
aheinecke triaged T6885: Forwarding mail with attachments embeded into the *.eml file will trigger GnuPG reporting an index out of range as Normal priority.
I have yet to reproduce this so I had not yet triaged this. The usual case to forward attached mail in Outlook is with .msg files but I recently noticed that Outlook on the web allows you to save mail also as .eml. Also .eml should in theory be much simpler to handle.
Dec 15 2023
Dec 15 2023
The issue was obvious but I looked at the wrong place. I looked for a ref counting error but the issue was that the control only returned a temporary pointer that had exactly one reference.
Dec 11 2023
Dec 11 2023
Dec 8 2023
Dec 8 2023
• ebo moved T6856: GpgOL is reported as slowing down the start of Outlook from Backlog to vsd-3.2.0 on the vsd32 board.
Dec 4 2023
Dec 4 2023
aheinecke triaged T6864: GpgOL: Invalid filenames are not checked for temporary files as Normal priority.
Nov 30 2023
Nov 30 2023
aheinecke triaged T6861: GpgOL: Crash when switching from calendar back to mailview as High priority.
Nov 29 2023
Nov 29 2023
I am closing this as resolved for now. I would need a completely new client or mess with the registry keys in which outlook stores the performance data to test this. But I would bet it still lists us as responsible for the slow start of outlook. But the time it will then show should now be 0ms since we absolutely do nothing anymore in our DLLMain.
I don't really know how to test this though since it tracks this over time and history. Let us see if my change fixes this, It may be that outlook does not measure the DLLMain (which I am pretty sure it does) but the actual COM initialization, in which case my change did nothing. But I don't see any way in which my change could make things worse.
I think outlook shows any native addin there. As you can see by the empty bar we don't really do anything in there to slow it down. But let me check if I can move the extremely little code we have in there somewhere else.
aheinecke triaged T6854: Kleopatra / libkleo: Improve tooltips for unusable keys in keyresolver as Low priority.
Nov 27 2023
Nov 27 2023
• ebo moved T6837: GpgOL: Keyresolver size default too small from QA to vsd-3.2.0 on the vsd32 board.
I can confirm this
Nov 25 2023
Nov 25 2023
Works nicely for me in beta300
aheinecke moved T6837: GpgOL: Keyresolver size default too small from Backlog to QA on the vsd32 board.
aheinecke changed the status of T6837: GpgOL: Keyresolver size default too small from Open to Testing.
The Keyresolver did not allow me to encrypt to an S/MIME cert where the root CA was not in my trustlist.txt that was part of this feature to allow users to encrypt "non vs-nfd compliant" to such untrusted keys, like they would be able to also encrypt to untrusted openpgp keys.
Nov 24 2023
Nov 24 2023
I am temped to put the VSD-3.2 flag on it and raise prio to high because of strategic reasons... So if someone has a cheap fix for this. Please go for it.
aheinecke added a comment to T6828: GpgOL: Decrypting encrypted drafts with S/MIME smartcard results in Operation Cancelled.
Similarly if you decrypt with a PKI BW card and the mimeviewer there are also no longer problems which again might be related that the internal states where somewhat disturbed by the loop in Kleopatra.
aheinecke closed T6828: GpgOL: Decrypting encrypted drafts with S/MIME smartcard results in Operation Cancelled as Resolved.
I retested this with the current beta and It works without problems. I somehow suspect that the permanent access loop from Kleopatra caused other Smartcard operations to be canceled. Since the test setup is not really good to reproduce to for Ebo I resolved this myself.
aheinecke moved T6828: GpgOL: Decrypting encrypted drafts with S/MIME smartcard results in Operation Cancelled from Backlog to vsd-3.2.0 on the vsd32 board.
• ebo moved T6823: GpgOL: Security Approval reports "Operation Failed" error if key generation was canceled from Restricted Project Column to Restricted Project Column on the Restricted Project board.
Nov 23 2023
Nov 23 2023
• ebo moved T6823: GpgOL: Security Approval reports "Operation Failed" error if key generation was canceled from QA to vsd-3.2.0 on the vsd32 board.
• ebo added a comment to T6823: GpgOL: Security Approval reports "Operation Failed" error if key generation was canceled.
Works on windows, too. VS-Desktop-3.1.90.295-Beta
• ebo moved T6813: GpgOL: Key generation window does not close from QA to vsd-3.2.0 on the vsd32 board.
works, VS-Desktop-3.1.90.295-Beta
• ebo moved T6566: GpgOL: newly generated key not loaded in the security confirmation dialog from QA to vsd-3.2.0 on the vsd32 board.
• ebo added a comment to T6566: GpgOL: newly generated key not loaded in the security confirmation dialog.
works, VS-Desktop-3.1.90.295-Beta
aheinecke moved T6823: GpgOL: Security Approval reports "Operation Failed" error if key generation was canceled from Backlog to QA on the vsd32 board.
aheinecke moved T6827: GpgOL: Check S/MIME draft encrypt and use GPGME_ENCRYPT_ALWAYS_TRUST from WiP to QA on the vsd32 board.
aheinecke moved T6813: GpgOL: Key generation window does not close from WiP to QA on the vsd32 board.
Nov 21 2023
Nov 21 2023
ikloecker changed the status of T6813: GpgOL: Key generation window does not close from Open to Testing.
I have added a workaround and tested it on Windows. Works now for me, including T6566.
@ikloecker I suggest giving up on this, I know that it is frustrating but it does not make much sense, it is probably related to some compiler settings / Qt cross compile issue and might be a bug in qt. Just do an old style connect and leave a comment that we will revisit this with Qt6. When VSD 3.2 is our last major release based on Qt5 we should not spend too much time investigating this which might be completely different (or not) with Qt6.
Nov 20 2023
Nov 20 2023
ikloecker moved T6813: GpgOL: Key generation window does not close from Restricted Project Column to Restricted Project Column on the Restricted Project board.
And it's the signals that are not found. I don't see any indication that this has anything to do with the slots/lambdas.
Well, the failed new style connects are logged for me with "QObject::connect: signal not found in QGpgME::QGpgMEQuickJob". I haven't dug into how the check works for those connects. It turns out that none of the three connects to the signals of QuickJob work (two of those connects are done in ProgressDialog). Even the connect to the argument-less done() signal. So this has nothing to do with default arguments. This is very disturbing because this means that any other connect might also be broken.
Ah no I see the difference here. Instead of connecting to a lambda with no args 96da231f97eff9485f62ab925d81252f5f97fc31 connected to the functions which were used in the old signal / slot syntax. I think the fix might be to explicitly list the args of the quickjob result or to use afunction to handle the keygenresult.
works, VS-Desktop-3.1.90.287-Beta
It does not log failed connections but new style connections are never logged when they fail. Since they can't fail ;-)
aheinecke moved T6813: GpgOL: Key generation window does not close from Backlog to WiP on the vsd32 board.
aheinecke raised the priority of T6813: GpgOL: Key generation window does not close from Normal to High.
Let me put this on the 3.2 workboard since we already have the "reports error when canceled" on that workboard and T6566 too depens on this, in fact I am currently working on this even though it was not on the workbaord.
• ebo added a comment to T6566: GpgOL: newly generated key not loaded in the security confirmation dialog.
Seems T6813 blocks me from testing this. The generate window does not close and even if I abort the window, the generated key is not loaded. It is not selectable even if I remove the filter.
aheinecke triaged T6828: GpgOL: Decrypting encrypted drafts with S/MIME smartcard results in Operation Cancelled as High priority.
aheinecke moved T6566: GpgOL: newly generated key not loaded in the security confirmation dialog from WiP to QA on the vsd32 board.
Does Qt log failed connections?
Nov 19 2023
Nov 19 2023
aheinecke changed the status of T6827: GpgOL: Check S/MIME draft encrypt and use GPGME_ENCRYPT_ALWAYS_TRUST from Open to Testing.
aheinecke added a comment to T6827: GpgOL: Check S/MIME draft encrypt and use GPGME_ENCRYPT_ALWAYS_TRUST .
So I tested this with an S/MIME certificate for which the CRL was not available and as described by the original reporter Outlook just froze. And you had to kill it. With the current beta you would get the dialog to encrypt the message anyway but this does not make sense for draft encryption where you can only select your own keys.
Nov 18 2023
Nov 18 2023
aheinecke triaged T6827: GpgOL: Check S/MIME draft encrypt and use GPGME_ENCRYPT_ALWAYS_TRUST as High priority.
Nov 16 2023
Nov 16 2023
aheinecke placed T6566: GpgOL: newly generated key not loaded in the security confirmation dialog up for grabs.
Merci vielmals. Cherry-picked.
aheinecke added a project to T6823: GpgOL: Security Approval reports "Operation Failed" error if key generation was canceled: vsd32.
I cherry picked it anyway. See my notes in T6813 I think I will at least workaround that one tomorrow.
Mh, I found some commits related to that 0796e04aa43c4500fb0f2c378b9a6cadf53a0a94 a43080fb0472afb46726cc555efffa102de9c7cc 810ed7b374f38eb7e038a83a557c8b6b91a65da3 if I remember correctly I even discussed this with Thiago and or David Faure back then and we figured it was a problem with default arguments. And there might have been a difference in KDE Compile settings and the compile settings with which QGpgME are compiled. It is pretty weird though even after some searching I can't find an initial commit from me that might be more verbose about the topic then just "Again new style connects won't work".
Eva said this worked with older installers. Otherwise, she wouldn't have reported T6566 as-is. What changed is that we now use QuickJob/QGpgMEQuickJob instead of DefaultKeyGenerationJob (the one defined in QGpgME).
ikloecker changed the status of T6566: GpgOL: newly generated key not loaded in the security confirmation dialog from Open to Testing.
ikloecker changed the status of T6823: GpgOL: Security Approval reports "Operation Failed" error if key generation was canceled from Open to Testing.
This may not be reproducible on Windows for the same reasons as T6813.
Me neither. But I take this since I can better debug this on Windows directly since this seems to be a windows only issue and it might be a build issue.
aheinecke added a project to T6823: GpgOL: Security Approval reports "Operation Failed" error if key generation was canceled: libkleo.
Not important for VSD 3.2 but yes I would like to see that fixed. Especially since we want the resolver also in KMail.
ikloecker added a comment to T6566: GpgOL: newly generated key not loaded in the security confirmation dialog.
Fixed with the above two commits.
ikloecker moved T6566: GpgOL: newly generated key not loaded in the security confirmation dialog from Backlog to WiP on the vsd32 board.
ikloecker moved T6566: GpgOL: newly generated key not loaded in the security confirmation dialog from Restricted Project Column to Restricted Project Column on the Restricted Project board.