Thank you for your suggestions, @werner.
I agree that we should not put much effort to develop our own methodology here; Too much effort may introduce possibility of unmaintainable code, which should be avoided for the particular purpose of "integrity".
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 16 2022
Feb 15 2022
Sure. We'll bump the SONAME.
In T5834#154975, @ikloecker wrote:I assumed that changes to internal classes wouldn't break the ABI, but apparently the symbols were still exported. I'll keep this in mind for the next release.
FWIW, the internal class in question was completely rewritten. Since the damage has been done already, I'll close this report. We won't readd symbols to dead code. Sorry, for the inconvenience.
Folks, you are opening a can of worms. The only secure why to sign a file is to have a detached signature. That is often non-practical and thus putting the signature/MAC at one certain position and exempt just this one position from hashing is the next best alternative. Any more complicated rules will inevitably introduce security flaws. If a binary is stripped, it is a different binary than a non-stripped one, if it is linked with another linker, it is a different one. And that binary will even be able to figure this out and change behavior. Please keep it simple.
Thanks! Maybe it would be simpler to use dl_iterate_phdr(3) for this. I wasn't aware of the function, but a colleague just implemented a proof-of-concept of what you're proposing in https://gitlab.com/dueno/integrity-notes.
I assumed that changes to internal classes wouldn't break the ABI, but apparently the symbols were still exported. I'll keep this in mind for the next release.
I am going to apply https://gitlab.com/redhat-crypto/libgcrypt/libgcrypt-mirror/-/commit/64ccc25c4b4a2c8c4e13e7e37ff1c8c60a3d8401
And consider adding the code to limit hashing content (from start of the file to end of data section).
Guess why GnuPG has its own Tor aware resolver ;-) To debug this kind of stuff you need to debug dirmngr, by adding for example
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