Sure that TB uses GPGME - they claimed they won't use it due to license incompatibility (LGPL). I assumed they use gpgme-json via naticve messaging. Regarding the error - I have no idea.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 19 2021
Jan 12 2021
Long since resolved
Jan 11 2021
Jan 8 2021
Jan 5 2021
Taking since I ran into this problem while working on T5174. In Kleopatra, if one opens the certificate details of one's own keys (i.e. secret key is available), then the tags vanish from the key list.
The C++, CL, Javascript and QT Bindings are all written by hand.
Hi Werner,
we do it for the other bindings as well. |
can you elaborate?
Given all the resources we had put on this Python bindings I'd suggest to bite the bullet and replace Swig by handcrafted bindings. More work but we do it for the other bindings as well.
Dec 12 2020
You're right. Thank you.
Dec 3 2020
Thanks. Fixed in rM7a4fe82a017b: python: Fix key_export*..
Dec 1 2020
Nov 26 2020
For ctx->exportPublicKeys returning 0 even when a failure, (with fix of gpg) error handling should be done differently.
Nov 25 2020
Well, I fixed my loopback passphrase provider and the application no longer crashes with a bad passphrase.
relatively new feature
Yes. In the mean time, I'm using a cheap workaround : validate the input passphrase by signing a dummy text before exporting. Not that ugly and can stay for long.
More specifically, in the situation of multiple calls, ->getPassphrase is called multiple times, and it should return newly allocated "char *" object each time, because it is released each time (in lower layer).
My excuse: Please note that the support of exporting secret keys by GPGME are relatively new feature (see {T5046) and the fix rM3382ecb17eb5: core: Support exporting secret keys.). The fix of rM53ac732bae46: core: Call _gpgme_passphrase_status_handler when exporting keys. is a part of the support.
I think that we need more fixes for gpg/gpgme to be fully working well.
Nov 24 2020
In T5151#139410, @gniibe wrote:when passphrase is wrong, the passphrase callback is called more than one time (one for primary key, and another for a subkey, more if there are more subkeys).
Currently, gpg doesn't report any errors to status line for exporting secret keys. If needed, a patch like this is needed:
Chasing this bug, I pushed a change: rM53ac732bae46: core: Call _gpgme_passphrase_status_handler when exporting keys.
Nov 23 2020
In T5151#139353, @nmset wrote:Using Context::setExpire(), expiry time of keys and subkeys can be changed in a predictable way, with good and bad passphrase (fails with error of course).
In T5151#139330, @ikloecker wrote:I highly recommend to use the new ChangeExpiryJob instead of the fragile (and apparently buggy) edit interactor.
In T5151#139332, @ikloecker wrote:Can you try if using the overload
Can you try if using the overload
Error Context::exportPublicKeys(const char *patterns[], Data &keyData, unsigned int flags)
which takes an array of patterns instead of a single pattern also crashes?
Unless you need some special features of GpgSetExpiryTimeEditInteractor or you have to support gpgme <1.15, I highly recommend to use the new ChangeExpiryJob instead of the fragile (and apparently buggy) edit interactor.
Nov 22 2020
Nov 20 2020
Nov 19 2020
Nov 18 2020
Fixed. Workaround for gpgme 1.15 (and earlier) implemented in Kleopatra: Do not call setRemark() with an empty QString.
I think Kleopatra is affected. It calls setRemark() on the job unconditionally with the text from the widget, and I'm pretty sure that this text is empty but not a null QString, if the user doesn't enter a remark.
Ingo, can you please check? I guess we are not affected because Kleo already checks for an empty string. But dkg's suggestion sounds good to me.
Nov 13 2020
Nov 12 2020
Thanks for your report, but your excerpt is irrelevant.
Push the change.
Thank you.
Nov 11 2020
Oct 28 2020
Pushed the change.
Oct 27 2020
IIUC, fix can be like this:
diff --git a/lang/python/src/core.py b/lang/python/src/core.py index 996c3b0f..646bbc60 100644 --- a/lang/python/src/core.py +++ b/lang/python/src/core.py @@ -147,7 +147,12 @@ class GpgmeWrapper(object): gpgme.gpg_raise_callback_exception(slf) return result
Oct 3 2020
Oct 1 2020
Good catch. Thank you.
Sep 26 2020
Sep 18 2020
Sep 7 2020
Sep 5 2020
The following patch make it work:
Sep 2 2020
Aug 29 2020
FWIW, here an example of warnings we use. Yes it starts with -Wall but there are a couple of more specific warnings and at a few places we even use pragmas to disable warnings. And it depends on the compiler version used.
Aug 28 2020
-Wall is not a good idea in general because it is too unspecific. This is why we have a list of useful warning and >warnings we ignore with gcc.
-Wall is not a good idea in general because it is too unspecific. This is why we have a list of useful warning and warnings we ignore with gcc.
I found the bug by compiling the package with C/C++ compiler clang and flag -Wall.
Fixed in gnupg and gpgme. it is not serious because that is just a failsafe check; libksba creates these strings and it does it correctly.
We have the same flaw in gnupg.
Aug 14 2020
Fixed.
Aug 13 2020
Taking: Still does not work although now --quick-set-expire is used by gpgme.
We won't do such a interface now.
Aug 12 2020
Aug 6 2020
Thanks. rMdb82e99 resolved this.
I just ran the test suite ~10 Times with -j48 on a 12 core machine and cannot reproduce this at all with GnuPG-2.2.21 and gpgme-1.14.0 so I tend to put this on resolved, otherwise this is a candidate for an issue that will be indefinetly in the tracker which we cannot reproduce or analyze further.
The t-json failure is: T4820
Thanks, I've applied this with an explicit include to <cstdlib> it was not required on Linux and Windows but I think it's better not to rely on internal libc++ include chains.
Thanks for your report.
Aug 5 2020
According to OS X 10.9 man pages for getenv(3) (10.9 is what I have available), the source file editinteractor.cpp should include <stdlib.h>. Since its a c++ source file, I believe the include of interest is <cstdlib>. The man page also says the link library is -lc.
Jul 27 2020
Phabricator allows it again to upload patches. It's D507
Jul 17 2020
C++ interface is also availabale in 1.14.0 (see rM690d967196d9).
Jul 16 2020
No info received
I am not any longer interested to see the real cause; eventually we will replace it anyway with a modern CreateProcess.
Reconsidering this: Running the test suite with gpg1 is not a proper use case. gpg1 may be installed in addition to gpg but it should never be used on a build machine solely.
As of today we don't want to maintain another binding; see T3395
The Python bindings are troublesome enough; as of today we don't want to maintain a Perl module.
No info received in3 years.