- User Since
- Mar 27 2017, 4:49 PM (90 w, 1 d)
The reporter said that it did not work for him.
Mon, Dec 17
@werner what should the contents of the file look like?
Asked to raise the priority on this. The quality bar issue is T2103
Good to know. I thought that ocsp-signer was only used if ocsp-responder is explitly set. I've suggested the workaround in the Message Board.
that error means that the message was somehow corrupted during transfer. Are you maybe using ftp in text mode on a binary message for example?
You could ask your communication partner to send you messages in text (ASCII Armor) mode which is more robust.
In Kleopatra you can change that in Settings -> Configure Kleopatra -> Crypto Operations -> Create signed or encrypted files as text files.
On the command line you need to add "--armor" option.
In Wald someone reports that this also appears to happen when decrypting. https://wald.intevation.org/forum/message.php?msg_id=6377 Probably run-threaded will help to flush this out.
Even with the logging changes this still happens. I just retested it. Can't run Kleopatra on Linux with GPGME_DEBUG=9.
Fri, Dec 14
Got another reliable report in the Wald Forum about this. https://wald.intevation.org/forum/message.php?msg_id=6371&group_id=11
No I do not think so. Because that would already be currently the case. If you had a subverted Root CA of course you can attack. But we are only talking about CRL / OCSP here. A root CA that does not provide a CRL for certificate X is OK. As long as the Root CA that issued X issues a CRL for that. Well the usual CRL / OCSP denial of service is still possible but I don't see any subversion.
I wonder if the best thing here might be another flag in the trustlist to disable CRL/OCSP checks for a single root certificate chain. I had such a request in the Gpg4win forums. Someone had a single unreacable CRL / OCSP and had to disable globally all checks for all other certs, too.
Wed, Dec 12
Uhm, if this option is useful why isn't it default behavior?
Tue, Dec 11
Mon, Dec 10
- Again basically nothing GnuPG except the usual maintenance stuff.
I'm pretty sure I tested this in the past using the Outlook.com web interface. The mails should show with an unknown attachment (the signature). I can't think of any changes recently that would have changed it. I'll check again.
Fri, Dec 7
I don't think this works for me in that way.
Thanks. In the meantime GpgOL takes it's language from the Outlook configured display language setting. I'll add support for override locale to gpgol so that the locale is set accordingly
Should we close this or do you want to investigate why the segfault happened after the error?
I ran it with GPGME_DEBUG and it errors out at
GPGME 2018-12-07 10:34:32 <0x19c43> gpgme_op_genkey_start:293: error: Invalid argument <GPGME>
Just by going through the standard "new key wizard".
GPA 0.11.0-beta5 [70858dc]
Wed, Dec 5
Sounds good! I give it to me for testing / documenting this.
Is this fixed now?
Ben is not even subscribed to this issue.
With the volatility of gpgme-python I think that this can easily be merged. I did a quick review and it looked good to me.
Tue, Dec 4
Cool and yes, that could also be an option. I was explicitly told by KDE-Windows that this would work for them, too. The problem for me is that I feel comfortable to add a CMake Buildsystem for the Cpp and Qt bindings (maybe Python?). It would be very simple for me, I would not extend it to GPGME core, at least not at first. I could do that on GNU/Linux without having to test an MSVC build.
It will be more effort for me to make autotools work nicely with MSVC. I would have to test that etc.
Mon, Dec 3
Further discussion revealed that the main problem is QtWebengine, which is a requirement of KMail and basically a fully fledged web browser with millions of lines of code. QtWebengine is only supported for MSVC on Windows and a MinGW port is not feasible, so just compiling KMail with MinGW all the way through like I did in the past is no longer an option. :-(
I give this high priority. This blocks for over years that the KDE-Windows initiative provides a way to install the very good crypto MUA KMail on windows. They rely on MSVC. As a former member of that community I am a bit ashamed that I made it harder / impossible for them to build KMail with MSVC because I've moved it to GPGME proper.
I think that is something I want to grapple with next year. The maintainer of Gpg4win noted that they currently rely on the patches from:
It might also be noted there in the installation instructions that it might be better not to run the installer from the download folder. (internal tracker issue45)
- Mostly non GnuPG work.
- Usual community work.
- Looked at some GpgOL issues like ( T4241 which will be difficult but might open up new possibilities).
Wed, Nov 28
@werner Be my guest.
I'll leave the fallback to "just try to decrypt" in though because it is better then doing nothing like we did before.
Thanks, from that log I can understand the problem:
Mon, Nov 26
You are running in a codepath that means "Outlook told us this was S/MIME, but we have not seen the proper message headers and neither does the data look like it is S/MIME."
Sadly your log does not help much in that case because it marked the mail as bad and aborts.
I've changed that "marking a mail as bad" so that future logs will be more helpful and that it will still try to treat this case as "encrypted" maybe that will already work, although I doubt it. The log will at least be a bit more helpful.
As I see it Bernhard is just asking for the flat strucuture so basically some export script that creates the needed files on windows.
Gets reported multiple times and should be fixed for the next Gpg4win release as it is a bad first impression. (Although it can convert users to Kleopatra ;-) )
not yet, I try to get to it this week.
Tue, Nov 20
I'm closing this issues as "Invalid" because it is not an issue of Gpg4win. You can still comment and discuss here.
Ok. If you can confirm that then it means that my analysis is right. Still unexpected to get an error there. I have to do some more tests with Exchange Online but that would be another issue. If this issue is fixed by turning of debugging then it will also be fixed by my patches.
Mon, Nov 19
While I can't reproduce it myself (because I probably don't have the right mails in my exchange) looking at your log I think that I see the problem there might be an issue with the error handling in openProperty. So for old mails the openProperty probably fails because we have exchange online for that and the property is not yet available in Outlook and then the error is not correctly handled and it crashes.
3.1.5 was released on 13.11.2018
Was released with 3.1.5
Was released with 3.1.5
3.1.5 is released with this change.
This should work with Gpg4win-3.1.5
- Gpg4win Release and some minor fixes for that.
- Added a json testsuite to GPGME
- Added a multithread run test tool to gpgme
Nov 15 2018
You seem to accept it. So Normal Prio and assigned to you :-p
Just as a note: I think the main selling point of GnuPG is that its stable. We care about backwards compatibility and we (are || want to be) rock solid. Even if there is a rare race. With millions of installations, that race will happen regularly. So I really would like us to get all this fixed without losing to much performance by locking to much.
Happens though. With the test invocation above there is only one key in the keyring.