[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Long Wiki Edits Thread

#787

Not ready for a call for testers but would appreciate if you could revise the wording.

#788

Advanced security guide:

Experiment with these…

#789

Added to Top of my list along with

document multiple Qubes TemplateVMs:

wink, nudge, nudge @torjunkie :slight_smile:

#790

Thanks @0brand - linked all your pics and edited Screenshots accordingly. Pity about success message, I thought it stayed there until closed by user (or it used to).

ha ha - I’ll let you work your technical magic and come sniffing later on :wink:

Bump @Patrick

If you approve all that, it will be much easier to start fixing all the links from the 3 splits.

Plus, it improves the main ToC which is too chunky in that section I split into browsing, email & messengers, other anonymous services. (plus splitting off dev/license stuff into own section)

#791

https://phabricator.whonix.org/T141 -> Fixed.

Please close.

#792

torjunkie:

Bump @Patrick

If you approve all that, it will be much easier to start fixing all the links from the 3 splits.

Plus, it improves the main ToC which is too chunky in that section I split into browsing, email & messengers, other anonymous services.

Sure. Thanks for letting me know that this blocks things so I will
prioritize it. (Previously I didn’t prioritize since it looked like a
time consuming change.)

Unfortunately the accept revision button is broken perhaps due to recent
changes. Already notified mig5. I’ll review as soon I hear it’s repaired.

#793

Revision button should be fixed now! :slight_smile:

#794

Amazingly quick! Thanks for being so proactive :slight_smile:

I have another one for you:

When editing the wiki, I saw this error, which I’ve never encountered before:

Error 503 Backend fetch failed

Backend fetch failed
Guru Meditation:

XID: 543227909

Varnish cache server

Subsequent edits worked after refreshing the page.

Might be related to recent tightening of server config.

#795

Hi @torjunkie, thanks for the report…

Do you happen to know what time you saw this error (maybe UTC or CEST would be useful, to correlate with server time which is CEST, but whatever works for you if you can specify the timezone).

And/or what page you were editing at the time.

A 503 reported by Varnish means it couldn’t get a response from its backend Apache, which is a surprise to me, as that’s an area I didn’t touch recently (and I’ve touched a lot of areas! :slight_smile: )

One theory is the logrotate daily cron or something reloaded Apache at just that precise time (e.g a fluke) but knowing what time you experienced this will be useful. Unfortunately Varnish doesn’t really log anything so it’s hard to debug further.

A 503 would also occur if some sort of timeout threshold was tripped between Varnish waiting for Apache to respond - e.g if you’re uploading a very large file that might occur. So a bit of context might help track this down, so far not seeing much in the logs other than a 503 on the ‘Screenshots’ wiki page at 10:11AM CEST or so…

#796

Hi mig5,

Yes, that was me. I guess it was just a fluke(?) in timing.

Thanks for the education you’re giving everyone too in explaining things, it’s appreciated.

BTW phabricator used to be the real buggy Whonix sub-domain, often reporting some “clustered(?) exception error” (I think), and a refresh was required for the page to present properly.

But it seems fine recently, so fingers crossed.

#797

@torjunkie yeah, the Phabricator issue was due to ‘too many connections’ MySQL errors - a side-effect of its peculiar database design - and we recently saw it even impacts the wiki since they share the same MySQL server. Both issues should not reoccur :slight_smile:

The Varnish one remains a mystery, might need to add some logging and attempt to reproduce some other time. Curious if it was instantaneous or whether there was a long timeout first. Anyway, let me know if it occurs again.

#798

That was instantaneous after either hitting the “edit” or “preview” button.

#799

https://riseup.net/en/gpg-best-practices is nice although they recommend 3072 RSA which I see no reason for if we can easily use maximum key length 4096 RSA.

#800

I’m holding off on edits until the main ToC page is approved i.e. as this prevents me finishing off recent weeks of work (and satisifying my editing OCD). :wink:

#801

https://www.whonix.org/wiki/Documentation already is confirmed. It doesn’t show any edits. https://www.whonix.org/wiki/Special:UnreviewedPages also doesn’t list it.

#802

Pending approval:

http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/w/index.php?title=Documentation&oldid=34457&diff=cur

#803

Really strange. Since not shown anywhere. Check if done now please.

#804

Thanks! That’s done. Now I must fix a bunch of links.

-> Fixed Qubes/Install page

That testers wiki page needs a bit of a rework. They could test things that have failed in recent times e.g. Qubes or Whonix bugs maybe? E.g. upgrade to Whonix 14 applies proper anon tags etc

#805

Feedback regarding https://www.whonix.org/wiki/Tor#Entry_Guards:

https://github.com/QubesOS/qubes-issues/issues/3554#issuecomment-407609005

#806

My answer:

http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/w/index.php?title=Fingerprint&oldid=33831&diff=cur

[…]

For example, if a user connects from multiple physical locations with persistent guards/bridges, then an adversary capable of monitoring this network activity can recognize that all connections stem from the same person. This is why it is recommended to use methods which mitigate the risk, such as using new entry guards, configuring alternate bridges and so on.

Nick Mathewson from The Tor Project also suggests additional precautions when moving networks, including: [https://lists.torproject.org/pipermail/tor-dev/2013-September/005424.html tor-dev: entry guards and linkability]

  • [[MAC_Address|Spoofing the MAC address]] with randomized values on each move.

  • Absolutely preventing non-Tor connections.

  • Ensuring a unique set of entry guards (bridges) is used for each network the user connects from. Note: this is not a recommendation for non-persistent guards, because a hostile DHCP server might provide new IPs until a hostile guard is chosen.

  • Minimizing the threat of stored Tor state files which record every network visited.

We also note in guard fingerprinting section:

Every change of Tor guards acts like a fingerprinting mechanism, since other users are less likely to pick the same set. If the adversary is able to enumerate a user’s Tor guards, and later observes someone with the same set, the chance is high the two observations stem from the same person.

For these reasons the Tor Project changed its design in 2014 to have a solitary primary guard node, and increased the set period for guard rotation.

etc.

So if core Tor Project devs think it is a risk i.e. guard enumeration across possible different networks that the adversary is monitoring, then I think it is a realistic threat.

Particularly since he also advocates MAC spoofing etc in combination.

So, to put the Q back to Andrew, why is Nick Mathewson wrong?

PS Did I mention there are hundreds of broken links? I’m making my way through the entire ToC, but will take some time.