- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 14 2022
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.
It was addressed in rC04f325d8917d: released 1.1.4 as "(obsolete)" feature, in Aug 2001.
Feb 9 2022
In T5816#154715, @ikloecker wrote:Try gcrypt-devel@gnupg.org, i.e. without the lists subdomain.
Recently, the gnupg.org mailing list manager started to prepend the lists. subdomain to the List-Id (which caused my email filters to fail) and to everything else. Probably due to an accidentally changed configuration.
Instead, let us remove the feature.
Optional automatic retrieval after import of new OpenPGP keys is now also possible.