- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 14 2022
Found it: I did not initialize gpgme_op_interact's last parameter out with gpgme_data_new. The error is now gone.
As well as GnuPG VS-Desktop. 3.1.21. We should also do a new gpg4win release.
Instead of extending the context menu I have simply added a button next to the fingerprint which always copies the fingerprint without whitespace to the clipboard. Should also be better for accessibility.
Good to hear the cause.
I have added tooltips to the + ECDH and the + Elgamal checkboxes. Hope this helps.
If the user unselects + ECDH, then the checkmark before Encryption under Certificate Usage is removed. I'm not sure whether adding a tooltip would help if they don't notice this.
Since you are using C++, I suggest that you have a look at GpgSetOwnerTrustEditInteractor in the C++ bindings of gpgme. Have a look at QGpgMEChangeOwnerTrustJob in the Qt bindings of gpgme to see how it's used even if you do not want to use Qt.
Hi,
(Exec format error), read 0 bytes
Feb 13 2022
Commented out the problematic code and added notes.
Feb 12 2022
Feb 11 2022
Feb 10 2022
While searching for a solution to this, I found multiple reports of people that appear to be impacted by this 5 year old issue.
Did you make another request for locating keys via WKD after adding the debug flags? I'm asking because when I do this I get the following log:
2022-02-10 17:49:59 dirmngr[6780] listening on socket '/run/user/1000/gnupg/d.f3hdqcrmjwf98p87yqjmuctx/S.dirmngr' 2022-02-10 17:49:59 dirmngr[6781.0] permanently loaded certificates: 130 2022-02-10 17:49:59 dirmngr[6781.0] runtime cached certificates: 0 2022-02-10 17:49:59 dirmngr[6781.0] trusted certificates: 130 (130,0,0,0) 2022-02-10 17:49:59 dirmngr[6781.0] failed to open cache dir file '/tmp/tmp.8P2EakNghu/crls.d/DIR.txt': No such file or directory 2022-02-10 17:49:59 dirmngr[6781.0] creating directory '/tmp/tmp.8P2EakNghu/crls.d' 2022-02-10 17:49:59 dirmngr[6781.0] new cache dir file '/tmp/tmp.8P2EakNghu/crls.d/DIR.txt' created 2022-02-10 17:49:59 dirmngr[6781.6] handler for fd 6 started 2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> # Home: /tmp/tmp.8P2EakNghu 2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> # Config: /tmp/tmp.8P2EakNghu/dirmngr.conf 2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> OK Dirmngr 2.3.5-beta17 at your service 2022-02-10 17:49:59 dirmngr[6781.6] connection from process 6779 (1000:100) 2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 <- GETINFO version 2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> D 2.3.5-beta17 2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> OK 2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 <- WKD_GET -- werner.koch@gnupg.com 2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: libdns initialized 2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: resolve_dns_name(openpgpkey.gnupg.com): No name 2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: getsrv(_openpgpkey._tcp.gnupg.com) -> 0 records 2022-02-10 17:49:59 dirmngr[6781.6] DBG: chan_6 -> S SOURCE https://gnupg.com 2022-02-10 17:49:59 dirmngr[6781.6] number of system provided CAs: 390 2022-02-10 17:49:59 dirmngr[6781.6] DBG: Using TLS library: GNUTLS 3.7.3 2022-02-10 17:49:59 dirmngr[6781.6] DBG: http.c:connect_server: trying name='gnupg.com' port=443 2022-02-10 17:49:59 dirmngr[6781.6] DBG: dns: resolve_dns_name(gnupg.com): Success 2022-02-10 17:49:59 dirmngr[6781.6] DBG: http.c:1917:socket_new: object 0x00007f524c290e20 for fd 7 created 2022-02-10 17:50:00 dirmngr[6781.6] DBG: http.c:request: 2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> GET /.well-known/openpgpkey/hu/waoubdep9643akkesx4xm3ynstfffiok?l=werner.koch HTTP/1.0\r\n 2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> Host: gnupg.com\r\n 2022-02-10 17:50:00 dirmngr[6781.6] DBG: http.c:request-header: 2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> \r\n 2022-02-10 17:50:00 dirmngr[6781.6] DBG: http.c:response: 2022-02-10 17:50:00 dirmngr[6781.6] DBG: >> HTTP/1.0 200 OK\r\n 2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Date: Thu, 10 Feb 2022 16:49:59 GMT' 2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Server: Boa/0.94.14rc21' 2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Accept-Ranges: bytes' 2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Connection: close' 2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Content-Length: 957' 2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Last-Modified: Mon, 28 Jun 2021 17:47:11 GMT' 2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: 'Content-Type: text/plain' 2022-02-10 17:50:00 dirmngr[6781.6] http.c:RESP: '' 2022-02-10 17:50:00 dirmngr[6781.6] DBG: (957 bytes sent via D lines not shown) 2022-02-10 17:50:00 dirmngr[6781.6] DBG: chan_6 -> OK 2022-02-10 17:50:00 dirmngr[6781.6] DBG: chan_6 <- BYE 2022-02-10 17:50:00 dirmngr[6781.6] DBG: chan_6 -> OK closing connection 2022-02-10 17:50:00 dirmngr[6781.6] handler for fd 6 terminated
2022-02-10 17:07:35 [12256] dauerhaft geladene Zertifikate: 74 2022-02-10 17:07:35 [12256] zwischengespeicherte Zertifikate: 0 2022-02-10 17:07:35 [12256] vertrauenswürdige Zertifikate: 74 (74,0,0,0) 2022-02-10 17:07:35 [12256] DBG: chan_0x0000026c -> # Home: C:\Users\User\AppData\Roaming\gnupg 2022-02-10 17:07:35 [12256] DBG: chan_0x0000026c -> # Config: .\dirmngr.conf 2022-02-10 17:07:35 [12256] DBG: chan_0x0000026c -> OK Dirmngr 2.3.4 at your service
From the external test and review of the test results I list the priority below. Some of the issues need to be reproduced for full understanding. We should open subtasks where appropiate. To have a better orientation I think we should keep the general prioritization in mind and work use case by use case.
This still seems to be a problem:
You can close this ticket. It's a jail-specific behavior when the jail is entered from the host via command line (https://lists.freebsd.org/archives/freebsd-hackers/2022-February/000832.html for the curious people) and something is used which closes all FDs. When the jail is accessed via ssh, it works.
user@debian:~$ gpg --debug-all --keyserver hkp://keyserver.ubuntu.com --recv-key
s DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: reading options from '/home/user/.gnupg/gpg.conf'
gpg: reading options from '[cmdline]'
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_3 <- # Home: /home/user/.gnupg
gpg: DBG: chan_3 <- # Config: /home/user/.gnupg/dirmngr.conf
gpg: DBG: chan_3 <- OK Dirmngr 2.2.27 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_3 -> GETINFO version
gpg: DBG: chan_3 <- D 2.2.27
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KEYSERVER --clear hkp://keyserver.ubuntu.com
gpg: DBG: chan_3 <- OK
gpg: DBG: chan_3 -> KS_GET -- 0xDF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: DBG: chan_3 <- ERR 219 Server indicated a failure <Unspecified source>
gpg: keyserver receive failed: Server indicated a failure
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg: build=0 update=0 insert=0 delete=0
gpg: reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/65536 bytes in 0 blocks
Actually is was/is a chain of bugs due to changing some URLs in confirmation mails from http to https.
GpgOL 2.5.2 has been released
I think this will break the build if kleopatrarc does not exist (because of the set -e). This may be intended, but in the commit log you wrote "[...] if it exists". I would have expected a test -f.