To extend on this: dlopen'ing of gpgme is NOT SUPPORTED. It is in general not a good idea to do this on standard Unix systems. On Windows we could make it work because DLLs on that platform are well designed and not a hack like the Unix shared objects.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 28 2021
Jul 27 2021
We really want thunderbird users that interact with GPGME to have a great and stable user experience, but the problem with dynamic loading and self compiled versions is that we cannot really know the build settings and enviornment and it is very time consuming to reproduce that. GPGME does some very low level things for optimized IPC that can depend on build options etc. This is why I am mostly in favor that thunderbird ships a defined version that we can debug and see the settings.
Reading the mozilla entry more carefully, there still seems to be an issue.
https://blog.gerv.net/2012/01/mozilla-projects-and-gpled-code/
@kaie, thanks for the pointer!
Jul 26 2021
In T5250#148131, @bernhard wrote:BTW @kaie
Thunderbird cannot use anything requiring GPL in its default configuration, because Thunderbird wants to distribute a single MPL licensed package that includes all components that are required for OpenPGP.
Any pointer why, they have made that choice, though? A bundle of MPL and GNU GPL components is fully allowed by the licenses as far as I know.
Sorry, I don't understand what you are trying to say, so let me give you some more detail.
@aheinecke Please test this on Windows
Huh, can't believe I somehow missed that this actually got a reply three years ago...
Everything in ~/.gnupg is and has always been private to gnupg unless explicitly stated otherwise.
Jul 25 2021
For many years I was convinced that my secret keys are stored in an encrypted folder. The .keyring file was there, everything looked correct...
Jul 24 2021
Using GPGME is probably the best way, even if gpgme-json might also work for some operations.
Jul 23 2021
Jul 22 2021
It's worth noting that this issue is particularly impactful for devices with small screens whose sizes cannot be changed. A Raspberry Pi with an Adafruit touchscreen would almost certainly have issues, for example.
This also applies to mobile devices. For context, I use Termux on my Android phone, and this issue manifests there. I can enter the passphrase for an existing key and decrypt/sign with it, but any attempt to create a new key throws me into the same loop that the OP describes. (Interestingly, this happens whether or not I actually supply a new passphrase.)
Since I am on a mobile device in this scenario, my terminal dimensions are 56x115. I'm not familiar with the implementation details of GPG, but is there any chance we could fall back to a single-line, sudo-style password prompt if pinentry fails (or have pinentry fall back to that internally if the normal mode fails)? That should work on terminals of just about any size.
(As an additional note, I've also tried flipping into landscape orientation, hoping that would increase my screen width sufficiently. However, my keyboard then occupies most of the screen, and I receive the expected error message, gpg: agent_genkey failed: Screen or window too small.)
EDIT: I'm running GPG 2.3.1 and pinentry 1.1.1.
Implemented for X11 and Windows.
Jul 21 2021
ok i found it just add "trust-model always" in gpg.conf
ok i found it just add "trust-model always" in gpg.conf
now its importing keys but it dosent trust them do you know how to fix this?
gpg2 --verbose --no-secmem-warning --no-greeting --auto-key-retrieve --no-tty --batch --yes --status-fd=2 --encrypt --armor -u <key-id> -r <email> -r <key-id> --output -
gpg: using subkey <sub-key> instead of primary key <primary-key>
[GNUPG:] KEY_CONSIDERED <key-id> 0
gpg: using pgp trust model
gpg: This key belongs to us
gpg: data source: <keyserver>
gpg: armor header: Comment: <key-id>
gpg: armor header: Comment: Name <email>
gpg: pub rsa4096/<key-id> <date> <name> <email>
gpg: key <key-id>: public key "<name> <email>"
imported
[GNUPG:] IMPORTED <key-id> <name> <email>
[GNUPG:] IMPORT_OK 1 <key-id>
gpg: Total number processed: 1
gpg: imported: 1
[GNUPG:] IMPORT_RES 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0
gpg: auto-key-locate found fingerprint <fingerprint>
gpg: using subkey <sub-key> instead of primary key <primary-key>
[GNUPG:] KEY_CONSIDERED <fingerprint> 0
gpg: automatically retrieved '<email>' via keyserver
gpg: <sub-key>: There is no assurance this key belongs to the named user
[GNUPG:] INV_RECP 10 <email>
[GNUPG:] FAILURE encrypt 53
gpg: [stdin]: encryption failed: Unusable public key
Hmm your log does not seem to indicate that the key is requested by GnuPG,
e.g. something like
rmngr[6077.5]: DBG: chan_5 <- KS_GET -- =bernhard@intevation.de
is missing.
OK, thanks for the explanation. But I think that the documentation should be slightly changed to say that the mapping is hardcoded. Otherwise, this may surprise users of different machines with different GnuPG versions (or in discussions between different users), who would see different behaviors when the mapping changes.
GnuPG 2.2.29 does not use keys.gnupg.net anymore. What it does is mapping keys.gnupg.net that is read from an (old) keyserver setting in the configuration files to a (hopefully) working keyserver. The documentation of gpg and dirmngr does indeed still mention keys.gnupg.net. The main problem with updating the documentation is that there isn't a good replacement for keys.gnupg.net and since keys.gnupg.net still works (via the aforementioned internal mapping) it is probably the best option for now.
For the evolution command i get:
2021-07-21 03:04:06 dirmngr[2421] listening on socket '/run/user/1000/gnupg/S.dirmngr'
2021-07-21 03:04:06 dirmngr[2422.0] permanently loaded certificates: 129
2021-07-21 03:04:06 dirmngr[2422.0] runtime cached certificates: 0
2021-07-21 03:04:06 dirmngr[2422.0] trusted certificates: 129 (128,0,0,1)
2021-07-21 03:04:06 dirmngr[2422.6] handler for fd 6 started
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> # Home: /home/<user>/.gnupg
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> # Config: /home/<user>/.gnupg/dirmngr.conf
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> OK Dirmngr 2.2.27 at your service
2021-07-21 03:04:06 dirmngr[2422.6] connection from process 2419 (1000:1000)
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 <- GETINFO version
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> D 2.2.27
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> OK
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 <- KEYSERVER --clear hkp://<keyserver>:8080
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 -> OK
2021-07-21 03:04:06 dirmngr[2422.6] DBG: chan_6 <- WKD_GET -- <email>
2021-07-21 03:04:37 dirmngr[2422.6] DBG: chan_6 -> S SOURCE https://<domain> #the domain dosnt has a WKD service
2021-07-21 03:04:37 dirmngr[2422.6] number of system provided CAs: 143
2021-07-21 03:04:47 dirmngr[2422.6] DBG: http.c:request:
2021-07-21 03:04:47 dirmngr[2422.6] DBG: >> GET /.well- known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>
HTTP/1.0\r\n
2021-07-21 03:04:47 dirmngr[2422.6] DBG: >> Host: <domain>\r\n
2021-07-21 03:04:47 dirmngr[2422.6] DBG: http.c:request-header:
2021-07-21 03:04:47 dirmngr[2422.6] DBG: >> \r\n
2021-07-21 03:04:47 dirmngr[2422.6] DBG: http.c:response:
2021-07-21 03:04:47 dirmngr[2422.6] DBG: >> HTTP/1.1 302 Found\r\n
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'date: Wed, 21 Jul
2021 07:04:45 GMT'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'server: Apache/2.4.41 (Ubuntu)'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'location: https://www.<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'content-length: 347'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'content-type: text/html; charset=iso-8859-1'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'strict-transport- security: max-age=15768000'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: 'connection: close'
2021-07-21 03:04:47 dirmngr[2422.6] http.c:RESP: ''
2021-07-21 03:04:47 dirmngr[2422.6] URL 'https://www.<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>' redirected to 'https://www.<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>' (302)
2021-07-21 03:04:47 dirmngr[2422.6] redirection changed to 'https://www.<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>'
2021-07-21 03:04:47 dirmngr[2422.6] DBG: chan_6 -> S WARNING http_redirect_cleanup 0 changed from 'https://<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-host>' to 'https://www.<domain>/.well-known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>'
2021-07-21 03:04:57 dirmngr[2422.6] DBG: http.c:request:
2021-07-21 03:04:57 dirmngr[2422.6] DBG: >> GET /.well- known/openpgpkey/hu/qhff8o86zx5pf4qa1w59eh6ohtnb8w44?l=<local-part>
HTTP/1.0\r\n
2021-07-21 03:04:57 dirmngr[2422.6] DBG: >> Host: [http://www.<domain>\r\n]www.<domain>\r\n
2021-07-21 03:04:57 dirmngr[2422.6] DBG: http.c:request-header:
2021-07-21 03:04:57 dirmngr[2422.6] DBG: >> \r\n
2021-07-21 03:04:57 dirmngr[2422.6] DBG: chan_6 -> S PROGRESS tick ? 0 0
2021-07-21 03:04:57 dirmngr[2422.6] DBG: http.c:response:
2021-07-21 03:04:57 dirmngr[2422.6] DBG: >> HTTP/1.1 404 Not Found\r\n
2021-07-21 03:04:57 dirmngr[2422.6] http.c:RESP: 'date: Wed, 21 Jul
2021 07:04:55 GMT'
2021-07-21 03:04:57 dirmngr[2422.6] http.c:RESP: 'server: Apache/2.4.41
Jul 20 2021
i dont have one what shoud i put in it
i dont have one what shoud i put in it
Tried it myself, getting the pubkey seems to work here.
Debian gnupg Version: 2.2.27-2~bpo10+1
Yes same result
Jul 19 2021
Did you try "--auto-key-retrieve"?
The comand that works says:
For formatting there are four modes: Formatting forced off (the default)/force on/on/off. The latter two modes allow the user to change the option.
This is a duplicate of T5522: gpgme: qt: t-various.cpp TestVarious::testSignKeyWithExpiration fails on 32 bit.
Jul 18 2021
Jul 17 2021
Jul 16 2021
Can you show the output of the command that works and the command that does not (and gets called by evolution),
please also add a "-v" to the options.
This key server also dosnt work
It could also be a problem of the keyserver (some hagrid instances are known to deliberately break RFC4880), can you try with a different keyserver, e.g. http://keys2.andreas-puls.de/.
And... as long as I read the PCT patches, it is not needed to export those API to users.
It is only needed internally for PCT tests (at most).
I am considering API enhancement, for this task.
This rwlock guarantees access with ctrl->card_ctx is always valid.
Jul 15 2021
[[ URL | foreach ($list as $item) {
work_miracles($item);
} ]]
Forgot to mention one thing: after changing my user folder directory I lost all my Outlook contacts. I was able to recover them... make sure you have a backup before attempting this!
Jul 14 2021
Jul 13 2021
I went through the patches above + what I suggested in previous comments, tested everything against both upstream and libgcrypt in Fedora in FIPS mode. There were slight differences, some cases were already fixed in master, some needed to upstream some of our changes, but the result is 10 patches working in both FIPS and non-fips mode, hopefully enough annotated. If not, please, ask for clarifications.