disable onions by default due to unreliability

At the moment we enable both, onions (primary) and clearnet (fallback) apt sources.

Proposed change: disable (comment out) onions by default

Reasons: Enabling it was an experiment which failed. Unreliable, bad usability (many support requests), reflects badly on Whonix.

Once Debian provides onion v3 with onionbalance which works reliable we may reconsider.

Once reliable we may even implement:
use onion sources list exclusively for apt-get updating by default

Then in this case add ssl/tls to whonix clearnet repo, because using http repo still reflects badly on whonix. (Debian and Qubes both have ssl support repos).

deb.debian.org instead of us.debian.org and use https (SSL, TLS) by default

Qubes uses http, not https by default. See:


deb [arch=amd64] http://deb.qubes-os.org/r4.0/vm @DIST@ main

for Qubes this will be changed according to:

and whonix if a new version gonna come up then thats needs to be in the favor of user privacy not reverting things against the user privacy. so if not onion then ssl , but not zero.

also Debian they have V2 onion repos which is better in this case than Whonix even when using HTTPS repos.

and why we should use the default things to be secure? because thats back to the distro design which meant to be secure (&anonymous) in order to protect user privacy as much as possible. and i dont see using onion v2 or v3 or ssl things are impossible to implement by default.

OK. Makes no sense to use something that works every now and then.

Sounds good.

With how bad TLS breaks apt in some cases we should pass. Also no point if it is not using Let’s Encrypt certs.

Not done as per Egypt and UAE HTTP Repository Manipulation/Poison · Issue #4415 · QubesOS/qubes-issues · GitHub

Not sure it was clever by me to mention public perception.

If it’s just public perception it’s best to be quiet about it. No one going to dig deep and few going to complain.

https is going to reflect badly due to amazon AWS as per:

But it’s not a popularity contest.

I am not totally convinced that SSL makes things more secure either.
Note: talking about security, not about privacy.

  • gpg verification: considered strong and not broken

  • https:

  • attack surface increased to both, the SSL verification code as well as the gpg verification code

    • stacking up code can lead to a bigger code base that has to be trusted
    • how could the gpg verification code be even attacked if SSL prevents any MITM from delivering malicious files?
      • Well, the files are provided by mirrors which are considered untrusted. Otherwise if SSL was so great we could in theory rely on SSL only and disable gpg verification.

But it always seems a good idea to combine levels of protections, and well, it’s what everyone is doing.

Do you mean https (SSL / TLS) by default broke apt-cacher-ng apt package caching during build or something else?

https (SSL / TLS) by default broke apt-cacher-ng apt package caching during build is non-trivial but solvable somehow.



1 Like

onion v2 still valid choice and reliable and better than ssl , whether its for whonix or for debian or for both. aws or not , not much to care about since its debian.

A major issue is users are not updating their system due to .onion unreliability. I’d rather take the time to give a link so a user can add .onion repositories. (then knows where to look to see how to revert to http//uri when .onion repos are down). Less support requests this way too.

.onion repos are for advanced users so this makes sence until v3 has better reliability. Even then, still for advanced users IMO.



1 Like


deb.debian.org instead of us.debian.org and use https (SSL, TLS) by default

This is now in stretch-testers repository.

1 Like

http://vwakviie2ienjx6t.onion/debian down for me. Works for anyone else?

1 Like

Works for me. ™

1 Like

Can you open http://vwakviie2ienjx6t.onion/debian in a browser?

For me:

Not Found

The requested URL /debian was not found on this server.
Apache Server at vwakviie2ienjx6t.onion Port 80

Other onions working.



The web server probably isn’t configured to try it as a directory without the “/”


Just an “update” to this thread, the problem with onions are still the same, unreliable for updates unfortunately.

1 Like