A few more things before you consider shipping this (sorry for not thinking of them before my previous email):
- torify is just a wrapper around torsocks. The tor package might be installed but not running, or some people might have machines with torsocks configured to talk to a remote Tor daemon. We should fall back at runtime if connecting via tor fails - this would probably even make the code clearer? - It would make sense to call the "--isolate" option in torsocks, otherwise this potentially identifies the tor circuit which the rest of your traffic is using, via e.g. the time of the cronjob, or at least highlights that it's a Debian system - I think the suggestion to have a separate default URL for tor submissions is a good one - if the HTTP default SUBMITURLS has not been changed, maybe switch to the tor one by default? And then insert the .onion URL when DSA kindly set it up. Kind regards, On 26 August 2016 at 23:13, Tim Retout <dioc...@debian.org> wrote: > Hi! I stumbled across this bug, and it looked like there were a > couple of issues with the previous version of the patch: > > - mentioned "sockproxy" instead of "torsocks" in one place > - disabling SMTP relied on USETOR=yes, but the torify function assumed > "always/auto/no" > > So I've updated the patch against the latest git, and changed to use > the "yes/maybe/no" convention. For completeness, I've added a FAQ > entry mentioning version 1.65, and attach /var/log/popularity-contest > after (hopefully) submitting it through tor (there was no gpg > extension, because it got moved to POPCONOLD). > > Technically I've not done further testing on this beyond running it a > few times, and I haven't checked for DNS leaks etc. via wireshark, so > "caveat emp-tor", so to speak? > > Kind regards, > > -- > Tim Retout <dioc...@debian.org> -- Tim Retout <dioc...@debian.org>
