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:
#debIndex of /debian buster main contrib non-free #deb-srcIndex of /debian buster main contrib non-free
deb tor+http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian buster main contrib non-free
#debIndex of /debian-security buster/updates main contrib non-free #deb-srcIndex 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
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.
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.
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.
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.
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.
No, there was no bug - people were just prevented from editing completely. But i see wiki edit comments in recent times on unprotected parts of a page like “As I can’t edit your template, can you please update XYZ…” e.g. Bisq page was a recent example of that.
Alright - I think we should unprotect most, even if more than on 5 pages etc. When I originally set the protections the vast majority of templates had zero protections. Agree with the sensitive info templates though.