Has been released and confirmed to be working.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 14 2019
Fix is in, will be released with 3.1.10
Fix is in. Will be released with 3.1.10
This is resolved
It turned out to be a downstream issue and the change in message class was enough from our side.
This is fixed.
This was fixed with 3.1.9
This should be fixed.
Testing with the DGN certificate showed that GPGSM returns a signature verification error (invalid digest algorithm) in this case. So the signature summary is not even checked.
Jul 4 2019
Jul 2 2019
This issues is not really about the CRL's. GpgOL should not activate the EFail protection if a CRL check fails. That is the issue here.
We need to know the issuers of the CRLs under question.
See also T4538 which we can only fix in 2.2 after we have checked that this does not break the VS-NfD approval.
Jul 1 2019
Sorry for the delay, I was on my summer vacation ;-)
@joaociocca Can you please try to update to Gpg4win-3.1.9 and try again.
Jun 24 2019
I just received answer that this is still a problem in the current release.
Jun 19 2019
I'm so sorry. It was a problem with mail server, not a GpgOL bug.
Jun 18 2019
Jun 11 2019
Hi Andre,
Hi,
as usual, thanks for your help.
Jun 8 2019
I'm having a very similar problem in 3.1.5! Randomly, when I try to view a PGP-signed e-mail, nothing shows, both on preview panel and when I open the message.
Jun 7 2019
File->Save As now works for crypto mails. It saves the encrypted message.
This works now, the hidden BeforePrint Event enabled us to detect when a print happens and the old code to do blocking decrypts enabled the actual printing.
We also do not print "our categories" (encrypted message, level x trust),... anymore, even in quick print.
Jun 4 2019
The change in message class did not help.
Works for me
Jun 3 2019
May 28 2019
My understanding of this issue and the fix for it is that Outlook with exchange detects that our mails are S/MIME mails. As the attachments are modified by us outlook wants to save the changes on move. This fails because it can't do the crypto. Leading to the error. This also happens when such a mail is closed.
We did not remove the "<>" from the content id. This worked for the first display but when forwarding they got doubled and it broke.
The code had the assumption that a content-id
could only exist on an attachment for HTML mails as it otherwise
does not make sense.
May 27 2019
I was able to reproduce this when I forwarded the mail after opening it in a new window. Somehow that appears to influence it.
May 24 2019
May 20 2019
Closing this as the moving problem was fixed.
May 16 2019
That was obvious. rG6fc5df1e10129f3171d80cf731f310b9e8d97c26 fixes this.
When doing a "gpgsm --with-validation -k foo" (assuming you have a cert foo) gpgsm now goes into a loop and prints the certficates that match "foo" over and over again. I have not tested if it was caused by this change but I think it is likely.
I imported 39 certificate files at once with Kleopatra with about 700 certificates and it worked. Took a long time though so It would be nice if Kleopatra would show a progess indicator or some indication that the import is running. But this is a different issue.
May 15 2019
Or a better tl;dr; When you send mails without "inline" option everything is fine and standardized. The problem is that the old version of GpgOL that your college uses is too stupid to handle this ;-)
Yes your colleague should or basically needs to upgrade. 2.2.3 is very outdated. There are security issues that were fixed by then etc.
In T4515#125651, @aheinecke wrote:Hi,
What client does your colleague use so that you have to use PGP/Inline?
That format where the attachment is it's own PGP Encrypted file is very problematic. You basically have mutliple signature and encryption states. An attacker can easily remove or add attachments to the message. The attachment name is leaked. etc. Also see: https://wiki.gnupg.org/PgpPartitioned
Our opinion is that if you really _have_ to use PGP/Inline that you must do so manually using Kleopatra's notepad and Encrypted files.
I am a bit unsure if I just close this as "Wontfix" or move it to Wishlist. I think for now I go with Wishlist but do not expect that feature soon. At least until maybe some really important use case comes up.
Anyway, thanks for your feedback. It is always valuable to know what users would like to have.
Best Regards,
Andre
What client does your colleague use so that you have to use PGP/Inline?
May 14 2019
The last lines that the process currently holding wrote in the log:
To reproduce this issue I started Kleopatra with an empty GNUPGHOME and imported 10 S/MIME certs at once (which spawns a gpgsm process each) with enabled logging.
May 13 2019
May 6 2019
Mmh no. This needs to go into the resolver. If autoresolve is disabled we also want to have that functionality. Having the ca config in libkleo would also help to use the same values in Kleopatra for a CSR.
May 3 2019
Good to hear this request from someone else, this gives it more priority :-).
May 2 2019
But sadly I can't see any problem with the mail. Looking at the source of the mail it has the image as one attachment. That attachment is displayed. There are no other attachments part of the mail and so other clients also only show that one attachment.
May 1 2019
Apr 30 2019
I have sended the email...
Apr 29 2019
Without more reports and without the info needed to analyze this further I'm lowering the priority.
Apr 26 2019
I think this can go to wontfix for now. Inline PGP inside of S/MIME,.. well that is not good.
This was fixed.
Apr 9 2019
Unsupported protocol still means something with your GnuPG installation is strange.
Whats surprising me most here is that Kleopatra works for you.
Apr 8 2019
I've looked into it alot first: If I use outlooks builtin S/MIME support it also does not work for me, at least over SMTP. I see the attachments but they have unknown type and if I double click them I get errors.
This was fixed afaik in 3.1.7 please let me know if this still does not work for you.
Mar 28 2019
No more reports about this in a while.