Control: noowner -1 Control: tags -1 + wontfix On Tue, Jul 08, 2014 at 10:10:25PM -0400, Hans-Christoph Steiner wrote: > Thanks for writing this! This may seem like a trivial issue, but I think > it'll help a lot with the usability if users can use "http://"; with .onion > addresses. I have set up a test mirror of debian-security on a Tor Hidden I had played with implementing it in apt, but ultimatively decided that this is too much magic and potentially even dangerous to enable by default, which is why I am tagging this wontfix. The good thing about requiring 'tor+http' is that it is clear that this will either be sent via Tor or not at all. If just 'http' would be allowed this isn't clear anymore: It becomes system state dependent with silent "failure" modes. It is a frequent problem in user support channels that a program has "mysteriously" disappeared from the system – usually it turns out that the user missed the remark that apt is removing the package containing that program. Now, with a normal program the user will get an error while trying to start it. If the user had removed apt-transport-tor through everything "keeps working"… That is not so much a problem with .onion addresses, those would "just" end up as unresolveable domains – at least if you aren't talking to a rogue DNS server (and apt will actually not ask DNS servers about .onions by default because of that). It contains other anomalies through: What will happen if a "normal" http request redirects you to an onion address? (Remember, a MITM could be editing the http request). Following the request means that we potentially contact a MITM provided onion service which has a good chance of knowing your Tor identify now (the default tries to avoid that by host-specific circuits), but at least knows that you have a Tor setup. Same problem if you do the reverse as a rogue onion service who wants to figure out your non-Tor identity. That pre-depends on the user not having non-Tor traffic entirely forbidden of course, but not everyone has all the time on every system and as it isn't a trivial setup yet mistakes happen. As such, I prefer a one-time safe error if you happen to have forgotten to use tor for an onion address, rather than having it magically work, but hiding hard errors in the long run. It is also good for consitency as for the non-onion repositories you will need to use tor+http for exactly the reason I mentioned first anyhow. That said, if you really really really must, there are multiple options to have the "normal" http behave like tor+http, the simplest one might be to just set Acquire::http::Proxy. The way described in the README to disable http can actually be used to "redirect" it to another method, too, if you don't use the special value 'false' but e.g. 'tor+http'. But as said, I don't think this is a good idea by default – or at all. btw: If you happen to use an .onion address with http only: Err:1 http://vwakviie2ienjx6t.onion/ Direct connection to .onion domains is blocked by default. If you meant to use Tor remember to use tor+http instead of http. Disclaimer: This response pre-depends on the recently uploaded 0.3 version in combination with apt 1.3. Best regards David Kalnischkies P.S.: I clear the "Owner" field as evidently nobody was working on implementing this – which is what claiming ownership means: "I will implement that" to avoid duplicated work by multiple people working on the same bug at the same time.
Attachment:
signature.asc
Description: PGP signature