Using GPGME is probably the best way, even if gpgme-json might also work for some operations.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 24 2021
Jul 19 2021
This is a duplicate of T5522: gpgme: qt: t-various.cpp TestVarious::testSignKeyWithExpiration fails on 32 bit.
Jul 8 2021
rM6a79e90dedc19877ae1c520fed875b57089a5425 looks good
Jul 7 2021
Thanks for the reply, this source code file and suggestions are very useful. Let gpg execute commands is a solution, but it is not optimal compared to providing a functional interface.
In addition, it is reversible to revoke the subkey by expiring it. But I will use the solutions you provide at this stage, knowing that you have time to provide better solutions. thank you!
What do you mean by "exporting revocation certificates"? Once such a certificate is imported you simply export the public key including the revocation signature. Otherwise, simply takes the revocation certificates from ${GNUPGHOME}/openpgp-revocs.d where they are written to, if you generate a key. Kleopatra uses gpg directly to generate a revocation certificate mimicking what gpgme would do: See https://dev.gnupg.org/source/kleo/browse/master/src/commands/genrevokecommand.cpp.
Jul 6 2021
Jun 29 2021
Jun 26 2021
Thanks for the report. Fixed.
Jun 25 2021
Thanks for the report.
We need to see how to best fix this regression test for all Python versions.
Jun 24 2021
Was released with 1.14.0 see T4996
Jun 23 2021
Jun 22 2021
Jun 21 2021
Jun 19 2021
The problem has been solved by me, but this and the problem are still very strange.
Jun 17 2021
Please try the distributed binary version of gpgme from GnuPG or Gpg4win (which is usually a snapshot). As you might now, we don't support building on Windows - it may or may not work, we have no idea and don't suggest that.
Jun 16 2021
Let me explain this problem more clearly. GPGME did not correctly receive and parse the output from gpgconf. Looking at the log file, EOF was generated when 4096 bits were read. So in engine info, although the path is correct, the identification of the version number is 1.0.0, and there is only gpgconf in the protocol, but there are no protocols such as gpg, assume, etc., which just means that gpgme does not correctly identify the output of gpgconf in this environment Information to find other protocols.
At the same time, I verified whether the output in gpgconf and the path of the related configuration are correct (whether there is a corresponding tool under the path), these are all right, which is very strange.
This is the log file output after the GPGME DEBUG environment variable is set.
You should run your test program with GPGME_DEBUG set. This gives some insight. The code you posted is too sparse to actually see what you are doing or want to do or what is the bug. Maybe it is better to ask the gnupg-devel ML?
Jun 10 2021
Jun 3 2021
May 31 2021
Take care: It is not clear whether you may use a [C} subkey for certification. GnuPG currently accepts this but the RFC can also be read as primary keys needs to to do the certification.
For signing (aka certifying) another key you need a (sub)key with the "certify" capability. Your signing subkey can only be used for signing data but not for certifying keys. This isn't specific to gpgme. See https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.21.
May 28 2021
Yes, you need the secret part of the primary key. gpgme has this info but it is easy to miss. Even our gpgme/tests/run-keylist.c debug tool did not show it directly. I modified it to make this more clear, see the latest gpgme commit. Here is an example for my key:
$ ./run-keylist --verbose --with-secret 63113AE866587D0A keyid : 63113AE866587D0A caps : esc flags : secret upd : 0 (0) fpr 0: AEA84EDCF01AD86C4701C85C63113AE866587D0A grip 0: CE5C1F1B8C96F1A078A2D1932EEE738A854ED976 curve 0: ed25519 caps 0: sc flags 0: fpr 1: E05BA20ED4F17768613B03C53CD7B3A055039224 grip 1: 7A1E3130C9CBDBF203A0AD8E186D9C511D5019FF curve 1: cv25519 caps 1: e flags 1: secret fpr 2: 8777461F2A074EBC480D359419CC1C9E085B107A grip 2: FF35C6E765F440145095750DC97D43D496C5ABEA curve 2: ed25519 caps 2: s flags 2: secret
May 27 2021
May 23 2021
May 17 2021
Due to tax issues, we can't accept a donation as return on service. However, we will fix bugs anyway if possible,
May 16 2021
May 7 2021
You are welcome.
run-genkey is working fine in my test environment as well.
May 6 2021
This revision was committed with rM276187f6b62a: core: Extend gpgme_key_sig_t with trust signature members.
This is better name. My point was that if we ever use that to create such a field the developer should not assume that arbitrary REs can be used here. We need to have some practical value here and I would prefer to see only the domain name. However, OpenPGP allows for arbitrary REs and thus we may see them here. This is problematic but we can't do much about it.
Well, all I can say is that
./run-genkey --loopback "elektra testkey (gen-gpg-testkey)"
creates a key without any problems and without asking for a passphrase. Even, if I add the GPGME_CREATE_NOEXPIRE flag to the call of gpgme_op_createkey. At least, from a terminal.
May 5 2021
Thank you for your response! I tried out all variants of gpgme_pinentry_mode_t and implemented a passphrase callback (using gpgme_set_passphrase_cb as suggested). It turns out that the callback is not invoked at all. However, if I switch back to gnupg 2.2.27, the callback is being invoked and the key is being generated (using the passphrase specified by the callback, as expected).
The problem might be that gpg tries to ask for a passphrase which fails on the CI. Try setting a passphrase callback and setting the pinentry mode to loopback. See https://dev.gnupg.org/source/gpgme/browse/master/tests/run-genkey.c$435.
May 4 2021
Added documentation for the new fields.
- Renamed trust_regexp to trust_scope.
- Use part of _unused for storing trust_depth and trust_value.
Apr 15 2021
Mar 22 2021
Mar 1 2021
In T5250#143872, @kaie wrote:It seems gpgme-json is intended to execute in the Web JavaScript sandbox of a browser.
I said "we're offering the optional use of GPGME
At the time I started to add an optional binding from Thunderbird to GPGME, I wasn't aware of gpgme-json.
In T5250#141705, @werner wrote: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.
Feb 13 2021
There is still useful software working only with 2.7. So it is not the time to drop this.
Feb 12 2021
Feb 9 2021
Feb 1 2021
A public keyblock without a user id packet is non-compliant. I see no reason to provide a feature to created crippled data. We had all this discussions back in the early 90s regarding to self-signatures. OpenPGP spoke a final word on this in 1998 by making user ids and corresponding self-signatures mandatory.
Not exactly the answer I was hoping for..
Oops, that was an experimental feature never intended for a released version. Will be removed in a way that it does not leas to compile problems - just to be extra cautiousness.
Jan 28 2021
Jan 26 2021
Jan 20 2021
In fact, Thunderbird does not use gpgme-json, but loads the gpgme shared library at runtime. The interesting thing is that Thunderbird works fine if gpgOSX is used.
Jan 19 2021
Reading the bugzilla report it seems that TB is loading gpgme at runtime. In particular the hints on using externally build stuff (Homebrew) is worrying. Someone(tm) needs to check how gpgme is used by TB and that it is properly initialized. GPGME is actually not designed to be loaded at runtime but should be used as standard shared object or static library.
Thanks for the reply. Not sure about GPGME/gpgme-json. Anyway, it still ends up in gpgme code, isn't it?
I used to modify gpgme sources to receive more information about the issue.
Looks like the next step would be to modify gpg-conf and see what's going on there, or leave it to the Thunderbird developers.