- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 15 2022
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
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: