- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Aug 20 2018
Hi,
Can I ask if there is any update on the issue that I face?
Aug 19 2018
Aug 18 2018
Aug 17 2018
Thanks for your answer
Ok
Thanks for your answer
I'm not sure that I understand your Problem. It might be helpful if you could provide screenshots of your problem so that we can better understand it.
We are not a CA and do not provide certificates.
There is currently no ECC key support in the S/MIME component of Gpg4win. I've edited the task a bit to reflect that. So it is impossible to generate an ECC Key for S/MIME with Kleopatra.
Thanks for the information.
Aug 16 2018
In our implementation, DO 0x6E contains:
I don't understand the reason why 0x6E (Application Related Data) can be so long. What OpenPGP card implementation do you have?
Aug 15 2018
Aug 14 2018
Aug 13 2018
With certified keys the automation is working as expected.
Got a new OL 2013 test setup where this was finally reproducible for me.
Aug 10 2018
OK, I take this ticket.
Discussion on the #python IRC channel last night with another experienced SWIG developer (of a proprietary and unnamed software project) has provided ass itional evidence supporting the theory that the cause of the problems with getting the bindings to run on Windows systems is indeed directly caused by the fact that Windows users are compiling GPGME and the bindings with a different compiler and runtime than those used to compile whichever version of Python they have obtained from elsewhere.
Aug 9 2018
Well, I have already tried to explain the use case: To make using cryptography easier for our users (for most of them the command line is the hell ...) I have integrated GnuPG in our webmailer. The webmailer has a key management page where you can import and export keys (up- and download, import from mail, attach to mail etc.), where you can edit trust settings, and where you can sign other keys and revoke such signatures. The webmailer certainly does not offer all capabilities of GnuPG but certainly a substantial subset.
The option you mean is "Disable non-blocking encrypt / sign", correct?
It's english in the german dialogue, btw.
Thanks for the tests and the report.
This seems very special and I'm not sure if we should not say at some point that we won't add quick commands for everything ;-)
The crash on send should be avoidable by checking "Disable async encryption" in the options.
Yesterday I got a new OL 2013 test system with which I can reproduce the crash. So that will be fixed or worked around for the next release.
no. Outlook 2013 reproducably crashes on sending and won't toggle
encryption on.
Ok i saw they apply custom patches to _gpgme_mkstemp which are outdated and should be revisited, sorry for the noise
Aug 8 2018
Actually i have now more debug output and i think i found the issue
I close this for now, this seems a problem of the mingw packages in msys2
ping, what's the status of this bug? it has been in testing for over one year. is that the correct status?
Sure, this should work, local keys are preferred.
But can't I simply use the keys in my local keyring?
No you can not use an "external" Web Key Directory. The point is that the provider (your domain) should be the source of the keys as it already manages the mail account. ( For more info see: https://wiki.gnupg.org/WKD )
Thanks for the report. I've commited a fix. (Returning the c_str here is ok as the data is not meant to be modified once "action" is called)
Please let us know if you find additional issues.
I downloaded GPGwin v3.1.3 beta 20 today. The automatic key fetching fails in my case because we have no WKS. Never heard of that before.
Aug 7 2018
Or with both packages installed, could i maybe debug somehow where it searches?
BenM, msys2 uses pacman as packagemanager, all packages are build from source
There is the same bug and fix in function parse_key :
diff --git a/g10/parse-packet.c b/g10/parse-packet.c index 0d28e7ac1..b147179e2 100644 --- a/g10/parse-packet.c +++ b/g10/parse-packet.c @@ -2533,7 +2533,7 @@ parse_key (IOBUF inp, int pkttype, unsigned long pktlen, err = gpg_error (GPG_ERR_INV_PACKET); goto leave; } - ski->s2k.count = iobuf_get (inp); + ski->s2k.count = iobuf_get_noeof (inp); pktlen--; if (list_mode) es_fprintf (listfp, "\tprotect count: %lu (%lu)\n",
I misunderstood your original report.
Alternatively, if they wish to keep using the Python installer from python.org then they would need to drop MSys2 in favour of the same version of Microsoft Visual Studio used to compile the that specific version of Python with and use it to compile every part of the GnuPG stack, up to and including GPGME.
If that is indeed the case and the theory regarding runtime conflicts, currently under investigation in T3505 and T4086, also proves to be true; then MSys2 users and developers will need to cease using the precompiled versions of Python available from python.org and compile their own version of Python copy with MSys2.
Windows 10 was obtained last week and the process of preparing a Windows build env began earlier today.