v3 onions for essential Whonix defaults (besides sdwdate)

gpg:
Whonix’s default hidden service is still qdigse2yzvuglcix.onion for GnuPG in some of the Wiki documentation, is it not? Are there updated v3 keyservers that support hkp?

1 Like

See also:

No longer using qdigse2yzvuglcix.onion in Whonix wiki.

Welcome back! And please post again should this not been resolved by now.

1 Like

Thank you, Patrick.

I noticed that anon-apt-sources-list/etc/apt/sources.list.d/debian.list

still contains Debian’s v2 onions. See onion.debian.org (http://jvgypgbnfyvfopg5msp6nwr2sl2fd6xmnguq35n7rfkw3yungjn2i4yd.onion) for their v3 addresses.

Unsure whether applies anywhere in Whonix code - but if people are using v2 addresses from Tor Project, their onion.torproject.org also has a v3 overhaul.

1 Like

brilliant thanks for the update :

deb  tor+http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian          buster            main
deb  tor+http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian          buster-updates    main
deb  tor+http://5ajw6aqf3ep7sijnscdzw77t7xq4xjpsy335yb2wiwgouo7yfxtjlmid.onion/debian-security buster/updates    main

#deb tor+http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian          buster-backports  main
2 Likes

For any of the Devs or Wiki Maintainers:

I suggest from the root of the project’s source files you maintain, running:
find . -type f -exec grep -HnE "[^[:alnum:]][[:alnum:]]{16}\.onion" {} \;

To root out v2 onions in the source files. If help is needed with linking to the relevant v3 onions I will assist.

1 Like

Thanks - onionizing repositories wiki entry updated. I don’t think we reference Debian’s repo onions elsewhere in the wiki, but I’d have to search.

This config has been tested to work:

#deb Index of /debian buster main contrib non-free
#deb-src Index of /debian buster main contrib non-free
deb tor+http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian buster main contrib non-free

#deb Index of /debian-security buster/updates main contrib non-free
#deb-src Index of /debian-security buster/updates main contrib non-free
deb tor+http://5ajw6aqf3ep7sijnscdzw77t7xq4xjpsy335yb2wiwgouo7yfxtjlmid.onion buster/updates main contrib non-free

#Optional backports
deb tor+http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian buster-backports main

2 Likes

Updated. Please check.

1 Like

Good work - that looks right.

2 Likes

Thank you. regex contributions can be very helpful. Done.

mygrep -lrHnE "[^[:alnum:]][[:alnum:]]{16}\.onion"

This is now done.

1 Like

List of wiki pages with onion v2’s:

Didn’t check if any of these are essential and/or have onion v3 replacements. Help welcome!

1 Like

Great. I see a lot of references to DuckDuckGo’s service: they have not yet deployed any known v3 address. I wonder what your stance is on SearX as a model? They have a list of Tor instances here (http://searxspbitokayvkhzhsnljde7rqmn7rvoga6e4waeub3h7ug3nghoad[dot]onion/). I recommend replacing DuckDuckGo personally. I know that you made reference to the unknown connection between the published v3 onion for MetaGer; so perhaps that is out of contention for now.

I did try to update Footnotes in at least one Wiki entry to replace newsletter(dot)torproject(dot)org with its v3 onion - but was unable to do so. It seemed the {{Footer}} or somesuch was not editable.

There are some relevant v3 nodes for the crypto services that have been deployed.

Without being able to seemingly edit the Wiki as I expected I did not go very far into editing. Should everything besides the OpenPGP wiki be editable by world?

That’s my fault. Some time ago I set the majority of templates to be editable only by registered users with the applicable permissions - this was due to malicious edits.

The frequency of those has dropped off, so maybe it’s time to revisit that decision. I also see ‘normal’ users trying to fix issues in recent times, but being blocked by the protected template status.

@Patrick - thoughts? Maybe we just protect a handful of ones you really don’t want the ‘world’ to be editing. I don’t think there’s any easy way to do it though, from memory they were protected one by one.

Re: v2 onions - maybe move that entry to the long wiki edits thread. I suggest that if the applicable v2 onions don’t have v3 onions available right now, we remove the v2 reference and just insert the ‘clearnet’ address so we are ready for the next Tor version which kills off v2 completely. Otherwise users will complain about multiple non-functional references.

1 Like

torjunkie via Whonix Forum:

The frequency of those has dropped off, so maybe it’s time to revisit that decision. I also see ‘normal’ users trying to fix issues in recent times, but being blocked by the protected template status.

@Patrick - thoughts? Maybe we just protect a handful of ones you really don’t want the ‘world’ to be editing.

Yes. Let’s say if the template is used on more than 5 pages
(Template:Footer) or contains sensitive information
(Template:Project_onion) or is unlikely to change (template with TPO
onion) then keep it protected.

Also not sure… Is there / was there a bug? If a malicious edit
modifies a template, does it show up for anon (other) visitors (another
Tor Browser instance in different VM for testing)? Or it protected by
moderation queue from public view? There might have been such a bug.
Might be fixed now. If no such bug then malicious template editing is
much less of an issue.

I don’t think there’s any easy way to do it though, from memory they were protected one by one.

Re: v2 onions - maybe move that entry to the long wiki edits thread. I suggest that if the applicable v2 onions don’t have v3 onions available right now, we remove the v2 reference and just insert the ‘clearnet’ address so we are ready for the next Tor version which kills off v2 completely. Otherwise users will complain about multiple non-functional references.

Makes sense.

https://duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion/

already provided

Please provide evidence that it’s really hosted by duckduckgo and not a third party. I.e. duckduckgo itself mentioning this onion.

duckduckgo doesnt mention its onion v2 as well.

Patrick via Whonix Forum:

Duckduckgo mentioned its onion v2 did on duckduckgo official twitter account. That tweet was on web.archive.org when duckduckgo onion v2 was used as sdwdate onion source. See sdwdate git history and/or you might still find that tweet.

Yes true but not as tweeting with hey we have our server mirrored over Tor please use it, It was an answer to someone asked:

https://nitter.kavin.rocks/duckduckgo/status/1032178047405973505

currently the check of ddg onion mentioned:

still show onion v2.

From technical point view its impossible (unless there is a way im not informed with) to sign onion v3 with TLS used by ddg themselves and turned out to be a third party. (unless there is certificate hijacking done on ddg/digicert which is highly unlikely or lets say it wont happen)

So that onion v3 to ddg is authentic without the need to announce it.

1 Like

I overlooked the https. The certificate duckduckgo clearnet vs onion fingerprint doesn’t match. Anyhow. A valid TLS certificate with extended validation should be sufficient indeed. Can any service save the TLS certificate? Never mind. It’s onion is visible on clearnet HTTP headers. That is a very solid confirmation.

1 Like