I might have changed the caller (GpgME++) but what convinced me that the change in core is better is that op_keylist_next sets the return value to NULL on error.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 29 2018
I changed the interaction so that user can specify RSA or ECC, then when it's for ECC, specifying curve.
It looks like something wrong happened in scdaemon. Could you please try with following? .gnupg/scdaemon.conf
Since I don't have macOS environment and Yubikey 4 (I only have old Yubikey), I hesitated to claim this ticket. But it is me who should take this one.
Mar 28 2018
I also stumbled on this problem in the past. However, I did not changed it because I feared to break callers which expect that the passed key object is not changed on error. This may happen in a loop where you test for an ambiguous key and don't save zway the first retrieved key. In the error case (i.e. not ambiguous) this would dump the good key object.
Mr. Heinecke, to make sure, please note that despite the thread title these crashes happened with 3.1.0. beta 38. It would be sad if you do all of the tests and checks with 3.0.3
Apologies for not replying to your mail directly. I've marked it in my INBOX to do the test with 3.0.3 first but have not gotten around to it.
Funny thing, it worked for some time, now it's reproducably crashing again. This might be the better log file.
So, this is tested with 3.1.0 beta 38, reproducable crash
I answered by mail in this fashion:
Mar 27 2018
The severe delay caused by check-trustdb continues to cause problems elsewhere in the ecosystem. It would be great to try to address this so that GnuPG was more responsive for routine tasks like importing a single key.
Thank you for your answer ! :)
You can do a
Was reported to me again in the context of paperkey export / print secret key in Kleopatra.
Got it. This was a bug that was around for ages but only started to occur in the verificationresult when we started in 3.0 to show the KeyID / Options for the unknown certificates.
In my opinion we should assume that c:/ was meant.
Mar 26 2018
Under Wine it does not crash but returning an empty string is not a good idea in any case. The question is what to do with "c:". The usual meaning is to use the current directory of drive C. But that does not make much sense. Should we simply assume that "c:/" was meant?
I pushed two fixes. One which hopefully avoids the corrupted trustdbs and a second one to repair a version-record-only trustdb (the example file).
rO4c5eed308829 fixes this.
Again, thanks for your time testing it again.
- it is reproducible
- Kleopatra crashes at the end of the verification of a signature
- it is a openPGP signature
- please see first picture
- I have only openPGP certificates in Kleopatra
My test case is to import my pubkey and then run:
We don't support v3 keys at all.
Thanks for trying out the beta and your report.
Fix was released with GPGME 1.10.0