Long Wiki Edits Thread

torjunkie · January 21, 2018, 11:10am

Off topic:

Can be closed.

Since it was renamed to onioncircuits, packaged in Debian (onioncircuits - Debian Package Tracker) and iry had this added to Whonix 14 (anon-workstation-packages-recommended) already:

onioncircuits - Viewing the status and circuits of Tor

2. ⚓ T399 Switch Debian links in sources.list to .onion (.onions in sources list) is noted as done for Whonix 14, so I presume it can also be closed.

torjunkie · January 22, 2018, 3:25am

On Template “Payments”, suggest you change:

This is not tax advice. Corporations who purchase priority support packages may be able to tax deduct these as an expense. Ask a tax advisor.

To ->

This does not constitute tax advice. Corporations who purchase priority support packages may be able to claim these as tax-deductible expenses. First consult a tax advisor.

iry · January 22, 2018, 6:00am

The HTTPSEverywhereUserRules trick introduced in Adding User Rules section does not work anymore for me. This is probably due to the Web-extension migration on HTTPSEverywhere.

I have submitted an issue to see how we can get it work:

github.com/EFForg/https-everywhere

Using HTTPSEverywhereUserRules with WebExtensions

opened 05:47AM - 22 Jan 18 UTC

closed 07:06PM - 22 Jan 18 UTC

irykoon

Type: ruleset issue Dear HTTPSEverywhere Developers, I tried to use HTTPSE…verywhereUserRules in the latest Tor Browser according to [the instructions](https://github.com/EFForg/https-everywhere/issues/9958#issuecomment-321452120) by @Hainish : > To add custom rules, you can still add them to your HTTPSEverywhereUserRules path, and subsequently change the extensions.https_everywhere.webextensions-migrated pref to false so that the extension knows to run another migration. However, it seems there is no such a preference in about:config in TBB by default. Therefore, I opened the about:config in Firefox 57, finding a preference called `extension.https_everywhere.webextension-migrated` (which is different from what @Hainish said: `extensions.https_everywhere.webextensions-migrated`). To trigger a re-import of my custom rules, I did the following steps: - put my custom ruleset to HTTPSEverywhereUserRules direcotry - toggled the value `extension.https_everywhere.webextension-migrated` to false - created a new pref called `extension.https_everywhere.webextensions-migrated` and set the value to false - restarted the Firefox However, it seems the rules I set in HTTPSEverywhereUserRules does not work. For your information, the ruleset I used is Browser/profile.default/HTTPSEverywhereUserRules/WhonixOnion.xml . The content is as follows: ``` <ruleset name="Whonix Onion"> <target host="whonix.org" /> <target host="www.whonix.org" /> <target host="phabricator.whonix.org" /> <target host="forums.whonix.org" /> <target host="download.whonix.org" /> <target host="deb.whonix.org" /> <rule from="^https?://(.*\.?)whonix\.org/" to="http://$1kkkkkkkkkk63ava6.onion/"/> </ruleset> ``` I did notice that later, @Hainish said in #11977 that: > Adding new rules to the HTTPSEverywhereUserRules directory will not work after the one-time migration in the Embedded WebExtension (>= 2017.8.15) is performed. If you had old rules, they were migrated to the new extension. > To add new custom rules, you'll have to use the popup by visiting the https version of the site you want to add a rule for, clicking the extension icon, and clicking "Add a rule for this site". Therefore, would you tell me if HTTPSEverywhereUserRules is still supported by WebExtensions version? If it is supported, would you please educate me on: 1. How I can use HTTPSEverywhereUserRules in Firefox 57? 2. How I can use HTTPSEverywhereUserRules in Tor Browser 7.0? Thank you so much for your great work and time! I really appreciate it!

iry · January 22, 2018, 10:49pm

I got the answer from the HTTPSEverywhere developer:

HTTPSEverywhereUserRules/ is not supported with WebExtensions and won’t be supported. My understanding is that security restrictions for WebExtensions block it from reading from the filesystem in the way that the HTTPSEverywhereUserRules/ approach needed.

I have updated the Wiki page:

Patrick · January 24, 2018, 10:53pm

torjunkie:

On Template “Payments”, suggest you change:

This is not tax advice. Corporations who purchase priority support packages may be able to tax deduct these as an expense. Ask a tax advisor.

To ->

This does not constitute tax advice. Corporations who purchase priority support packages may be able to claim these as tax-deductible expenses. First consult a tax advisor.

Done.

(Plus another small change.)

Patrick · January 27, 2018, 1:25am

Should we ever move away from mediawiki to another web app… Please veto if you dislike the editing usability of the new web app…

I guess there is a reason why the Qubes website gets relatively fewer contributions… Github web editing is not comfortable…

Patrick · January 31, 2018, 11:42am

3 posts were merged into an existing topic: Forcing .onion on Whonix.org

Patrick · February 2, 2018, 12:53pm

Good read on USB security:

github.com/QubesOS/qubes-issues

Ease creating USB VM even if USB keyboard is used

opened 10:38PM - 01 Feb 18 UTC

closed 10:26AM - 02 Aug 22 UTC

marmarek

T: enhancement C: other ux P: default

Even if the system have only one USB controller, and only USB keyboard, creating… USB VM, with [`qubes.InputKeyboard` service, part of input-proxy, enabled](https://www.qubes-os.org/doc/usb/#how-to-use-a-usb-keyboard) still makes some sense. While USB VM will be able to spy and/or subvert the keyboard, user will see resulting actions. Malicious USB device will not be able to exploit some dom0 kernel driver, silently in the background. And when bundled with [some 2FA](https://www.qubes-os.org/doc/yubi-key/), malicious USB VM will not be able to unlock the screen on its own. Besides enabling `qubes.InputKeyboard` service, there is one more problem: USB controllers are blacklisted in dom0 (specifically: connected to xen-pciback driver, before loading actual USB controllers drivers) - this prevents entering LUKS passphrase using USB keyboard. For now, lets ease the basic thing: - do not blacklist USB controllers early (only just before actual starting USB VM) - enable qubes.InputKeyboard service To (semi-)securely use it, user is responsible for disconnecting any untrusted USB device from the system for the boot time. Note that this (unfortunately) should be a standard routine even in non-USB keyboard case, because BIOS (also having USB drivers) potentially could be exploited by malicious device at early boot stage too. Later, we can employ additional protection, using [usb device authorization](https://www.kernel.org/doc/Documentation/usb/authorization.txt), to allow only HID devices and only for the LUKS passphrase entering time. This is still far less protection than USB VM + input-proxy, but something better than allowing all devices. Some long term solution could be bundling minimal USB VM with input-proxy into initramfs, but at this level of complexity (and required work), it may be better to simply adjust hardware configuration instead (like installing separate USB controller for this). This is related to #2959, #2116, #3203

torjunkie · February 3, 2018, 7:27am

FAQ -> Done (finally)

I think we should cut the tiny section existing in it’s own page (VFAQ) into the FAQ itself and delete that VFAQ page. And also shift up FAQ to the Download section on main TOC page.

Agree?

@Patrick

I think when you did that auto-run on removing certain pages from translation in the last few days, it returned the page edits (including some templates) to their very old (rough) versions.

E.g. look at the Advanced Security Guide. It’s back to where it was a year ago (?) before I spent weeks (months?) fixing it up. There are multiple other pages like that.

Please revert that change, or whatever caused it. It would be very, very painful to try and track down each individual page manually that is back to old, dodgy English and revert them to latest edits.

I also noted Whonix Release Notes disappeared off the main TOC (why? same reason when doing some auto thing on the main documentation page?)

I’ll hold off on edits till then, because if all that work is lost for good…

torjunkie · February 3, 2018, 8:16am

I see it also affected DoNot, various templates etc.

Could also explain bad links and comments like this on Twitter today:

@Whonix Fix download link for virtualbox gateway/workstation!
View details · Reply Retweet Like

Patrick · February 3, 2018, 1:10pm

Weird. Thanks for noticing. Hopefully I figure out how to fix that.

It was never added as far as I know. For sure didn’t manually remove it. Thanks for adding it!

Patrick · February 3, 2018, 1:13pm

It’s official: I hate mediawiki translate extension!

If you find a broken page… Please go to history… Page → History

Permission error - Whonix

(Removed page from translation) (rollback 10 edits | undo)

I will try that.

Patrick · February 3, 2018, 1:23pm

Do you have a list of some examples of broken pages?

The good news is nothing is lost. For once, we have mysql backups (but then we’d loose the work after the translation unmark, so we’d need to back that up first before we roll back). Also not sure forum and wiki can be separately restored, fortasse would know. Secondly, if we can identify the broken pages, the rollback can be rolled back.

Patrick · February 3, 2018, 1:30pm

Basically just undo Removed page from translation. Not rollback. (That would rollback any changes by me alter later ones.)

Patrick · February 3, 2018, 1:33pm

Now - I really have to - temporarily - undo your last commit on /Documentation. Otherwise…

The edit could not be undone due to conflicting intermediate edits.

I keep a list of undone edits and then manually reapply.

Patrick · February 3, 2018, 1:39pm

<translate>, </translate> and such I can later remove with mass search and replace. For now, I just try to identify rolled back pages and roll them back. Hard, since the translation removal is not part of the log.

Patrick · February 3, 2018, 3:40pm

torjunkie:

FAQ -> Done (finally)

I think we should cut the tiny section existing in it’s own page (VFAQ) into the FAQ itself and delete that VFAQ page. And also shift up FAQ to the Download section on main TOC page.

Agree?

Yes. Feel free to move that page. Let the new FAQ be a FAQ and the VFAQ
can be moved elsewhere and/or moved to where appreciate.

Also some stuff like OpenBSD was a FAQ in past, but nowadays it’s not
being asked anymore. So FAQs naturally need cleanup. (So that
information could be moved elsewhere.) But perhaps no one asks about it
since the reply of this is easily found on google and the answer
prevents any further debate?

I think when you ran that auto-run on removing certain pages from translation in the last few days, it returned the page edits to their very old (rough) versions.

That should now all be sorted.

torjunkie · February 4, 2018, 1:18am

Thank God, I had a heart attack when I saw that!

The “tvar” variable has broken almost every link on the main Documentation page, so I’ve removed them, plus the “[languages/]” insert which was appearing in plain text, instead of doing anything useful.

torjunkie · February 4, 2018, 2:09am

You’ve opened up a can of worms.

Now the related issue is wherever the following text appears in individual wiki pages (that’s a LOT):

tvar
languages /
translate (ones you didn’t replace with “”)

It appears in plain text and/or breaks the embedded link. Damn.

Translation is a virus in mediawiki. Users should just be recommended to use Bing Translator which works in Tor Browser for whatever their issue is.

0brand · February 4, 2018, 11:03am

Hi Patrick & torjunkie

I just saw that well over half of the wiki TOC (links) are broken. Can I help?