Ah okay - no worries. They take a while to filter to stable. I’m very keen to see it implemented, as your stuff will save a lot of time and is a major improvement.
That’s great. Yes please, go ahead and edit away. I’ve added you as a maintainer of the page (pending edits), since who am I to question the OnionShare lead mechanic
And thanks for all your efforts on the website. It is running smoother than I ever remember, all the errors seem to have disappeared, and the v3 onion seems to be available all the time now. A truly shocking combination compared to previous times, and I think it wasn’t just luck! Maybe new hardware also helped?
Also, a suggested News Forum topic (if you like @Patrick , I’ll post it)
A Callout to Whonix Cryptocurrency Users
Dear Whonix users,
Recently, members of the Monero community approached us in the Organization forum about ways in which we could collaborate together. [1]
The Monero community has a reputation for being passionate about privacy and there are a significant number of users who also rely on Whonix for their activities. With obvious shared goals and interests, a number of Monero community members quickly came forward and provided detailed, fully-functional instructions for Monero on the Whonix platform. [2]
The Whonix team would like to thank OSNF2P, thotbot, rehrar and others for their efforts and ongoing maintainer status of the Monero wiki page.
Based on this success, we would like to welcome members from other popular cryptocurrency communities such as Bitcoin, Ethereum and so on to step forward and improve the existing Whonix wiki sections that already exist, but which are either out-of-date or unfinished. [3]
The wiki badly needs the love of afficinados who want a win-win for both communities: working crypto instructions combined with a higher-security, virtualized platform.
Anybody who is willing to contribute can freely edit the relevant wiki pages and/or nominate themself for maintainer status.
Thanks! No new hardware yet, so that’s a nice surprise.
We have a strange bug on Phabricator (the comment field has disappeared in tickets) which I can’t figure out, otherwise yes, things are stable. I upgraded MediaWiki overnight too to address some security issues, as well as Discourse.
After the Debian .onion drama on the weekend, I’ve added some monitoring of the content of the Whonix .onion front page too.
Why would Qubes-Whonix users need to manually configure the TemplateVM proxy (in Qubes R3.2?) as part of the “update”.
That is:
a) Should be already setup by users well before then either automatically at install; or
b) They would have already set this up when configuring Whonix the first time after manually downloading templates.
Since Qubes R4 is using Salt - doesn’t apply at all (normal update page is fine).
It only applies to Qubes R3.2, but I presume all the “preparation” steps can either sent to a separate “configuring sys-whonix as a ProxyVM” section somewhere (specific to R3.2), and the rest of the page is not needed (delete it), since it just repeats the same text as the update page (?) →
As of Tor Browser 8.5 it 's possible to save per site JS settings across browser resets. Changes are lost if security slider changed however. This feature however is not recommended and considered dangerous as unique JS settings make a user stand out.
Better to keep. Qubes-Whonix update instructions may always differ a bit
from Non-Qubes-Whonix. Since the shared contents is already in a wiki
template
Some things don’t apply to Qubes but I never prioritized to fix (remove
from wiki template, move to virtualizer specific instructions)
Restart Services After Upgrading - no need when shutting down
TemplateVM anyhow
Restart After Kernel Upgrades: no need when shutting down
TemplateVM anyhow / Qubes is using dom0 kernel anyhow unless people
follow VM kernel instructions (probably not much people)
Why would Qubes-Whonix users need to manually configure the TemplateVM proxy (in Qubes R3.2?) as part of the “update”.
I know you play with Firejail a lot. So Firejail from stretch-backports works for Debian VM (FF 62) in Qubes, but that “Gah! Tab Crash” thing still happens with Tor Browser in Qubes-Whonix using the same backports version?
Did you get it working? I was hoping to just put a footnote on our Firejail page that if the stable version doesn’t work, just install the backports version - but that’s not going to work apparently.
Surfing, Posting, Blogging → Fixed (for full edit)
I think also that Bitmessage info on the Email page should go to a separate page (detailed instructions are too long there; all other entries are relatively brief and point to their own page if necessary).
Maybe Firejail from experimental repo might fix it? Didn’t inspect that yet.
Thanks - will edit Firejail page to note if stable version is non-functional, then:
a) Try backports version 1st.
b) In desperation, edit FJ profiles manually.
This is no big deal, since we basically suggest the same kind of thing when AppArmor profiles break Tor Browser in Whonix.
Also, whoever did those onionizing edits today is pointing to non-existent files in dom0? I am missing something i.e. these proposed edits won’t work since Marek chopped those commit changes, yes? @0brand (I assume it wasn’t you, since the wiki edits were not up to your usual standard)
I was just following the edited instructions as they are written, and they are pointing to file(s) and talking about commenting blocks etc that don’t exist in my system.
Can we put you as maintainer of that page? In general, I think we are better off avoiding “comment this” “uncomment that” because too many steps = room for user errors (similar to old Bridge instructions).
Better for those sections is IMO:
Edit this file.
Cut and paste the following text (code select style)
And same error if you try the other Tor Browser profile.
WTF. Manual says “absolute path to profile” and gives examples very similar to above. How do we get Firejail to actually launch using the amended raw github profile because it is fucking annoying…
