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!
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
