12/02/2011 10:15 PM, intrigeri:
>> * Since we configured apt to use polipo on port 8118
>
> Was fixed for a while in my tree, but I forgot to push.
> I am sorry for the inconvenience it caused.
While it builds I still get apt-related proxy errors the stage after the
actual iso is created.
> About some of the last few "Torify $X" that were pushed to
> feature/no_transparent_proxy: I'm surprised they are needed, and the
> commit messages don't help me in any way understanding why they
> actually are which worries me slightly (call me a control freak if you
> want, I do like understanding what we put into our Git repository):
Yeah you're right. I'll rewrite the commit messages when I can verify
that no one else is working on that branch.
For the record, all my negative test results (and there was one for each
of these commits) comes from a build made on commit c38466e.
> - "Torify seahorse": does Seahorse really ignore the global GNOME
> HTTP proxy settings? Bug report?
When I did the tests the indymedia hidden service were unavailable, so I
tried hkp://keys.gnupg.net, which consistently failed without even
listing a connection in vidalia. Using torify immediately made it work.
Some minutes ago I booted up the same build and noticed that the hidden
service is back up. Somewhat surprisingly, searching and fetching keys
works without using torify. Did I have gremlins in my tubes earlier? No,
it seems. If I switch to keys.gnupg.net I still get the same problems as
I experienced before. Perplexing. I'll investigate this further
tomorrow. Wild guess: it has something to do with .onions getting
remapped by Tor to a virtual address (see the AutomapHosts* and
VirtualAddrNetwork options in torrc).
> - "Torify gobby": I'm a bit surprised it does not respect the GNOME
> proxy settings either, but not that much as Gobby is not part of
> GNOME AFAIK. Did anyone actually check this commit was needed
> in practice?
It's needed, see:
http://gobby.0x539.de/trac/ticket/426
> - "Torify HTP" (that actually torifies wget):
Woops...
> I'm surprised, again,
> to see wget does not take into account the http_proxy environment
> variable.
Init scripts are supposed to be self-contained w.r.t. to environment,
and in particular they don't load /etc/environment. Since there are
potentially other reasons for the environment to get lost I feel it's
safer to set the proxy it in wgetrc.
> - "Torify tails-security-check": I'd rather not use the
> /usr/bin/torify LD_PRELOAD hacks unless really needed; pushed
> fcd445c that directly use the Tor SOCKS proxy instead.
Actually before slapping on torify I attempted adding $ua->env_proxy
(which may be considered nicer than hard coding the proxy) but that
didn't work for some reason. I did verify that $ua->proxy('https')
contained the correct proxy address afterwards.
Cheers!
