GnuPG 2.1 & dirmngr handling #15
Comments
|
Hmm, odd. Can you try running gnupg manually with torsocks and seeing what happens? Something like (adjust as needed): torsocksConfig="/tmp/tor.$RANDOM"
echo "TorAddress 127.0.0.1" > "$torsocksConfig"
echo "TorPort 9050" >> "$torsocksConfig"
TORSOCKS_CONF_FILE="$torsocksConfig" torsocks gnupg --recv-keys "$keyID"That should more-or-less reproduce what |
|
It works when manually running Where Furthermore, I can reproduce the error on a fresh Fedora 22 install. If I configure Interestingly, when using |
|
I investigated a little: The command called by the script is If i run this with If I drop the http-proxy-option, the update succeeds. Additional information: |
|
The default It would also be possible to make users have to specify all Opinions? |
|
From "[Announce] GnuPG 2.1.0 "modern" released" (https://lists.gnupg.org/pipermail/gnupg-announce/2014q4/000358.html)
Running works fine without an error. If I run right after that, I still get tor traffic. I guess that's because the dirmngr daemon is still up and running with torsocks... Also, dirmngr only partially supports the http-proxy options see "dirmngr ignores honor-http-proxy and http-proxy options" (https://bugs.gnupg.org/gnupg/issue1786) |
|
Changing |
|
In order to keep ensuring that all key refreshes are done on unique Tor circuits, I think this means having to do the following, if a
That's a pretty roundabout way to go about it but I can't really think of a way that preserves parcimonie.sh's properties without preventing normal |
|
One could probably use namespaces instead of creating a temporary directory and symlink most files into it. See e.g. unshare(1) or nsenter(1). Downside: Linux-specific feature (I don't know how much you care about *BSD or *nix). |
|
In gpg2, gpg.conf provides a Wouldn't it be sufficient (although not perfect) to create a torifying wrapper for dirmngr that terminates dirmngr after some (e.g. 5) seconds? |
|
I'm a new user. I just experienced this same issue. Running this, I get the IPC syntax error: If I set My question is, when I set |
We need to set GNUPG_KEYSERVER_OPTIONS and pass something to address EtiennePerot/parcimonie.sh#15 I set no-honor-keyserver-url in my gpg.conf anyway. I think the option makes sense, so we'll use that until the parcimonie issue is resolved.
|
Maybe a temporary work-around (until a more complete solution can be written) could be to kill all running dirmngr just before and after a key is refreshed? The probability that this would take place as the same time as the user's gpg activity would be rather low. |
|
Sorry for not providing a fix, but still running into this 17 months after it was first reported, I would love to boost morale and thank everyone working on fixing this. :) Thanks! |
|
@loudfishmonger This set up is not safe, because it reuses Tor circuits across key refreshes. By setting
tl;dr: There are no perfect answers. One gleam of hope is that I propose to implement the following compromise. It is an extension of @Feandil's suggestion but with more implementation details, and protection against race conditions that could result in non-Tor usage. Preferences:
On start:
On key refresh:
This is still subject to a race condition in the form of the user manually refreshing a key while If there are no objections, I plan to implement this sometime this month. |
DNS is only leaked if DNS is used. For |
|
Doing that would force all users to use the same keyserver rather than being able to specify their own, which is a regression. It also doesn't solve the circuit reuse problem. |
Not quite. sks-keyservers.net sais:
Currently, that Tor pool consists of 15 of the 94 servers in the SKS pool, tendency: growing. Also, with onion, circuit reuse becomes less of a problem, since the threat level is an attacker on the server-side re-identifying a client re-using the same exit note. But an onion-server never sees an exit node, it only sees "a Tor user". Also, not only the client, but also the server could use a new curcuit after the random sleep. This is a good enough compromise for me not to need a guarantee for a new circuit on each connection. |
From GnuPG 2.1.17, |
|
Thanks @ilf, that's good to know. Unfortunately it means either doing version detection again, or just hoping that users will never use the prior versions... Using As for the |
EtiennePerot
changed the title
This currently does nothing, but it will be used to switch between the two modes of operation described in issue #15, depending on whether dirmngr should be used (GnuPG ≥ 2.1) or not (GnuPG < 2.1).
|
Even with the changes in 5aa21ef, I'm getting the IPC syntax error. Any idea what could be done here? Software versions (Fedora 27): My In |
|
@genodeftest That commit doesn't actually change behavior; it only implements the logic for finding |
We need to set GNUPG_KEYSERVER_OPTIONS and pass something to address EtiennePerot/parcimonie.sh#15 I set no-honor-keyserver-url in my gpg.conf anyway. I think the option makes sense, so we'll use that until the parcimonie issue is resolved.
|
Fedora is updating the default GnuPG to GnuPG2. I'm wondering whether we should also default parcimonie to GnuPG2, or if we should set GnuPG1 as default for the Fedora package? Currently, the standard configuration for parcimonie in Fedora uses GnuPG1. |
|
(perl) parcimone has also had a miserable time with dirmngr. Antoine Beaupré suggested ditching dirmngr and talking to the keyservers ourselves, observing that HKP is not hard. It's really just a bit of HTTP. So, something like this? recvKey() {
local fingerprint="$1"
local tmpdir="$(mktemp -d)"
local gpgtmp="${tmpdir}/gnupghome"
mkdir "${gpgtmp}"
chmod 0700 "${gpgtmp}"
local ok=no
curl -x "socks5h://parcimonie-${RANDOM}:parcimone-${RANDOM}@127.0.0.1:9050/" \
"http://jirk5u4osbsr34t5.onion/pks/lookup?op=get&search=0x${fingerprint}" \
>"${tmpdir}/response.dat" && \
gpg --homedir "${gpgtmp}" --import "${tmpdir}/response.dat" && \
gpg --homedir "${gpgtmp}" --output "${tmpdir}/response-filtered.dat" \
--export "0x${fingerprint}" && \
gpg --import "${tmpdir}/response-filtered.dat" && \
ok=yes
rm -r "${tmpdir}"
[[ "$ok" == "yes" ]]
} |
|
Is there a solution or workaround yet? |
|
I'm also still getting the same error message, but am not certain how to tell if it is actually the same cause. Is there any troubleshooting I can try to help? |
|
Still waiting. By the way, it might be good to integrate this feature into seahorse. |
Starting with gnupg 2.1.4 on Arch Linux, receiving a key always fails with the same error:
Updating the key manually works as expected:
With gnupg 2.1.3, this error did not occur.
My
gpg.conf:My
/etc/parcimonie.sh.d/user.conf:My tor config is the default of an up-to-date Arch Linux. Since tor was not updated with gnupg, I don't think the error is directly related to tor.
How to reproduce
I can only guess that it must be related to gnupg 2.1.4, as my configuration is probably the standard configuration:
Expected behavior
The key should be refreshed successfully.
Actual behavior
Receiving the key fails with the error shown above.
The text was updated successfully, but these errors were encountered: