Long Wiki Edits Thread

[0brand]

Testing completed “comments to use Qubes onion repository”

(https://github.com/QubesOS/qubes-issues/issues/2623)

AFAICT these are the files that require comments # .

• https://github.com/QubesOS/qubes-core-agent-linux/blob/master/misc/qubes-r4.list.in

• https://github.com/QubesOS/qubes-core-agent-linux/blob/master/misc/qubes-r4.repo

• https://github.com/QubesOS/qubes-installer-qubes-os/blob/master/qubes-release/qubes-dom0.repo.in

• https://github.com/QubesOS/qubes-installer-qubes-os/blob/master/qubes-release/qubes-templates.repo

These files do not require comments. Because they pull from fedoraproject.org not qubes-os.org

• https://github.com/QubesOS/qubes-installer-qubes-os/blob/master/qubes-release/fedora-updates.repo.in

• https://github.com/QubesOS/qubes-installer-qubes-os/blob/master/qubes-release/fedora.repo.in

If this is correct I’ll go ahead and make a pull request

---

@Patrick

Wasn’t part of this task however for future work:

• Could you please briefly mention Qubes template implementation, i.e. that cloning of VMs and centralized updates are a lot a lot better usability in Qubes? Also this greatly saves time (for cloning) and disk space.

Absolutely!

@Patrick

Cloning Multiple Qubes-Whonix TemplateVMs

Minor nit: -> Multiple Qubes-Whonix TemplateVMs

Cloning Multiple Qubes-Whonix TemplateVMs

Please add links to sections of Install Additional Software Safely

Ok

@Patrick

Could you please also explain what to do after cloning the TemplateVM? I.e. creating an anon-whonix-purpose based on that cloned TemplateVM? And pointing out that a separate TemplateVM needs to be updated separately?

I’ll have everything complete by later tomorrow.

@Patrick

Posting (larger) wiki edit suggestion to the forums first seems to create double work for the editor since discourse forums and mediawiki use different syntax. It’s also harder to see the actual diff .

Its a PITA

@Patrick

If one is insecure about suggesting (complex) wiki edits straight to admin confirmation mediawiki queue… What about making a copy of that wiki page to a temporary wiki page? Then edits could be tested out there. And if good, these could be copied back to the original page after review.

I thought posting here would make it easier for you and torjunkie to make remarks ( not having to copy and past from wiki to forum). Also I figured you may want to review some wiki edits remotely via forum e-mail (more convenient ?)

I’d be more than ecstatic to use a the wiki from now on Yah!

I usually have the wiki chapter formatted ready to go (saved) before I post in this thread so this will make it a lot easier for me. Plus i typically use the bottom of wiki pages to see how the new edits will look. The temp wiki page will come in handy!

[Patrick]

@0brand

If this is correct I’ll go ahead and make a pull request

Looks correct. I guess comments to use Qubes onion repository · Issue #2623 · QubesOS/qubes-issues · GitHub will be easily merged by Marek since it’s only comments from technical perspective so very very room to mess up things for most users / regressions. I interpret the silence in comments to use Qubes onion repository · Issue #2623 · QubesOS/qubes-issues · GitHub as non-controversy or perhaps low interest so probably ok.

[Patrick]

0brand:

I thought posting here would make it easier for you and torjunkie to make remarks ( not having to copy and past from wiki to forum). Also I figured you may want to review some wiki edits remotely via forum e-mail (more convenient ?)

Well, remarks can be directly edited in once the initial version was
posted to the wiki. We don’t have a policy of “only near-perfect
versions may be published”. If it’s good enough, it’s good enough as
first iteration and enhancements are welcome. I guess that is more
productive.

Seldom (or never? I don’t recall) an initial version is so bad that it
would need a major revision before it could go live.

[torjunkie]

Thanks for the footnotes thing!

Additional request: need to replace <references /> as well

(note the space between s and /)

This is present on some pages and wasn’t replaced in the previous round.

That’s great content @0brand. Agree with Patrick, better to either:

a) Put it on an unpublished test wiki page as Patrick said if you want any major edits from others; or
b) Just put it straight into a page, Patrick will publish it, and we’ll nitpick it?

You know your stuff so shouldn’t hesistate too much in this regard i.e. don’t sell yourself short and start doing more of (b). :-))

[0brand]

@Patrick

document multiple Qubes TemplateVMs :
https://phabricator.whonix.org/T811

Added to wiki along with

• mention Qubes template implementation
• explain what to do after cloning the TemplateVM

https://whonix.org/w/index.php?title=Multiple_Whonix-Workstations&oldid=35015&diff=cur

[Patrick]

Qubes-Whonix 14 / Qubes R4 DisposableVM support is mostly undocumented.

I suggest to modify Qubes Disposables according to the following plan:

• Whonix 13 DisposableVM: entirely unsupported
• Qubes R3.2 Whonix 14: entirely unsupported
• Qubes R4 Whonix 14: supported

[0brand]

@Patrick

Qubes-Whonix 14 / Qubes R4 DisposableVM support is mostly undocumented.

I suggest to modify Qubes Disposables according to the following plan:

• Whonix 13 DisposableVM: entirely unsupported
• Qubes R3.2 Whonix 14: entirely unsupported
• Qubes R4 Whonix 14: supported

Have a few smaller edits to complete then I’ll start on this.

---

Two wiki contribs.

Uploaded the last screenshot https://whonix.org/wiki/File:Screenshot-clone-vm-qubes.png

Added Screenshot Qubes-r4-create_sys-whonix.png to Template: Qubes Create Gateway ProxyVMs including content. (Using Admin privileges). Also, I failed to add a comment for the edits…again.

https://whonix.org/w/index.php?title=Template:Qubes_Create_Gateway_ProxyVMs&curid=3639&diff=35259&oldid=31851

[Patrick]

I’ve created a bit mess under Post-installation Security Advice. All the different cases are documented now.

suspend / hibernate in dom0: Generally ok in Qubes.

There is a difference in Qubes between suspend / hibernate in dom0 and pause / resume using Qubes VM Manager. The later is problematic usability wise.

suspend / hibernate / safe / restore / pause / resume in Non-Qubes-Whonix:
Generally problematic usability wise.

So maybe all of that documentation could be moved to an advanced place or hidden under an expand button? The simplified documentation could be:

• Non-Qubes-Whonix: stay away from suspend / hibernate / safe / restore / pause / resume. See link or press expand more complex answer.
• Qubes-Whonix: suspend / resume ok. Stay away from Qubes VM Manger pause/resume. See link or press expand more complex answer.

[torjunkie]

@Patrick

I’ve created a bit mess under Post-installation Security Advice. All the different cases are documented now.

I’ll have a look.

@0brand

Added to wiki

Excellent. Thanks for doing this, it was a real priority (I’ll also have a look at your recent edits soon, but they look great).

@0brand

then I’ll start on this.

Your advice to mig5 re: DispVM customization is suitable to be cut and pasted straight into a relevant section in your update BTW.

I think based on Whonix 14 being imminent and Qubes R3.2 being phased out in a little over 6 months, I agree focusing on Whonix 14 & R4 is best.

I’ll keep fixing links and minor edits, and then come back to backlog of larger things.

[Patrick]

password advice wiki page enhancements

That article needs more contents. Suggest different password per website. Not password1, password2, Password alike variations. Explain why that is. Attackers use passwords which were leaked in one website as templates so they don’t have to fall back on “totally” brute force attacks. Don’t use online password generators for anything but curiosity / learning. That is because there is a very good chance the server could log them. The only place where passwords should be generated is locally, id…

[0brand]

@torjunkie

Your advice to mig5 re: DispVM customization is suitable to be cut and pasted straight into a relevant section in your update BTW.

I made a bit of a mistake in the instructions.

Its not prefs templates_for_dispvms true that prevents Tor Browser from starting.

Its the dvm tag in the VM name anon-whonix-dvm that prevents Tor Browser start.

User would have to create an AppVM without dvm appended to the name. Customize Tor Browser (Noscript, Tor Browser security slider, etc). Then clone the AppVM with dvm appended to the name of the new VM. Then continue with the instructions using the new VM.

Instructions have been updated

However, to start Tor Browser in a dvm, the instructions Patrick provided makes more sense IMO:

https://whonix.org/wiki/Tor_Browser#From_the_Command_Line_or_Debugging_Mode

[0brand]

@Patrick

https://www.whonix.org/wiki/Software#Install_Software_in_TemplateBasedVM isn’t the best place?

• Maybe it would fit better her https://www.whonix.org/wiki/Install_Software ?
• Or better fit in some Qubes specific place?

Done!

Removed “Install Software in TemplatebasedVM” from #Software

https://whonix.org/w/index.php?title=Software&oldid=35007&diff=cur

Migrated to #Install Software

https://whonix.org/w/index.php?title=Install_Software&oldid=35195&diff=cur

[Patrick]

0brand:

@torjunkie

Your advice to mig5 re: DispVM customization is suitable to be cut and pasted straight into a relevant section in your update BTW.

I made a bit of a mistake in the instructions.

Its not prefs templates_for_dispvms true that prevents Tor Browser from starting.

Unfortunately not. I consider this an unclean implementation but for now
it’s the only possible way.

Its the dvm tag in the VM name anon-whonix-dvm that prevents Tor Browser start.

Nitpick: Let’s please not call it a tag to avoid confusion with Qubes
tags. It’s the VM name ending -dvm.

User would have to create an AppVM without dvm appended to the name.

That’s cheating. I don’t like that at all because in future we won’t
check for -dvm in VM name but use a proper check.

To avoid invalidating the instructions in future, I would prefer:

A)

/etc/torbrowser.d/50_user.conf

tb_qubes_dvm_template() {
   true
}

or B)

Manually starting Tor Browser while circumventing tb-starter
(/usr/bin/torbrowser).

or C)

I could easily implement a command line option --dvm-start or so to
allow running torbrowser --dvm-start and starting Tor Browser in DVM
Tempalte.

However, to start Tor Browser in a dvm, the instructions Patrick provided makes more sense IMO:

https://whonix.org/wiki/Tor_Browser#From_the_Command_Line_or_Debugging_Mode

The path is different. So Tor Browser Essentials
won’t work.

Just now documented here:
Tor Browser Advanced Topics

[Patrick]

Two-factor Authentication (2FA)

[Patrick]

Could you please add somewhere advice on how to increase the quality of entropy pool? That would be advisable before sensitive cryptographic operations such as generating a gpg private key or crypto currency wallet / mnemonic seed etc. As I understand the linux kernel developers, the kernel entropy can never get worse even if users manage to produce no entropy at all.

1. Write random keyboard glibberish to a text file.

cat random-file > /dev/random

[torjunkie]

@Patrick

That article needs more contents. Suggest different password per website.

No problem.

I can fix this as it just so happens I’ve gotten up to the Passwords section re: fixing links.

[0brand]

@Patrick

This very chapter: https://www.whonix.org/wiki/Dev/Qubes#Connection_through_Qubes_Updates_Proxy
Could you please test? And document a bit better?

Also the following…

Qubes R3.2

http_proxy=http://10.137.255.254:8082 gpg.anondist-orig --recv-keys ...

Qubes R4

http_proxy=http://127.0.0.1:8082 gpg.anondist-orig --recv-keys ...

Would then be possible. What would be a good place to document this?

The goal is for connecting without enabling networking in TemplateVMs? Correct?

• I’m not able to connect using default Qube-R4 (no network connection Templates)
• Can connect with network enabled in Template

Haven’t given up. Still researching.

@0brand

If this is correct I’ll go ahead and make a pull request

Comments to use Qubes onion repository

https://github.com/QubesOS/qubes-issues/issues/2623

Migrating from Github GUI to .git CLI

Taking a little longer than I had hoped (learning syntax).

[torjunkie]

@Patrick

Whonix 14 Release forum post nits:

• VirtualBox .ova and libvirt qcow2 raw images were reduced by 35% correct? (it says just .ova at the minute)
• Remove that “prefers onion sources line”, since that is no longer true.

Other than that - congrats on the release! Lets see how everyone goes upgrading/re-installing…

[torjunkie]

@Patrick

Please check my edits to upgrade instructions. One of those Qubes packages is now in the stable repo, not the testing one (I fixed that). But could be other minor errors.

Could be good to double check since Whonix 14 has been announced.

[Patrick]

torjunkie:

@Patrick

Whonix 14 Release forum post nits:

• VirtualBox .ova and libvirt qcow2 raw images were reduced by 35% correct? (it says just .ova at the minute)

Yes. Could you please edit the post (given moderation power)?

• Remove that “prefers onion sources line”, since that is no longer true.

It’s true. You might be misinterpreting some commit or forum message by me.

Other than that - congrats on the release! Lets see how everyone goes upgrading/re-installing…