Anyone feeling qualified to define
upgrade? Just synonyms? Could we fix their usage in Whonix wiki to make use of these terms more appropriate?
Whonix 13 deprecation notice completed. Not sure if this is how they should be written. Its all yours’ torjunkie (use it, or not)
Whonix 13 EOL
The Whonix team would like to thank the community member for all the hard work that was put forth into the support of Whonix 13 over that last 2 years. Through your efforts, Whonix 13 was a success and by and large surpassed all of expectations. With the release of Whonix 14, a decision had to be made as to whether it would be feasible to continue support of Whonix 13. Under ideal circumstances, Whonix developers would continue support of Whonix 13 for a period of time. However, due to the limited resources available, the date has been set for Whonix 13 to reach EOL on 2018 September 30. On this date, Whonix 13 will become deprecated and will no longer receive security updates.
Although Whonix 13 reaches EOL in 30 days, users not be alarmed as it is still safe to use and will remain so to until 2018 September 30. At the same time, users are strongly encouraged to upgrade to Whonix 14 as soon as possible to ensure there is ample time for a smooth upgrade. If users encounter and problems, please follow these instructions to submit a support request
PQCrypto page -> Fixed.
(I didn’t do those anon Qubes/DispVM edits BTW. Whoever that user is seems to be leaking their hardware or other identifiers looking at the wiki edits history page i.e. this ->
Should be a red flag warning to wiki editors if they have an incorrect configuration, no?
Wasn’t me either. Excited that we have someone else making contributions!
Created new Template “Qubes/Clone VM” but I’m not sure if this was created correctly? (first time I created a template)
Created new page Qubes/Clone VMs
Added to Multiple Whonix-Workstations
70defaultrelease works with no problems.
-t buster causes the same dependency problem that causes the current wiki instructions to fail.
Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libkf5coreaddons5 : Breaks: libkf5auth5 (< 5.47) but 5.28.0-2 is to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
It looks like no
-t option for now, but there is another option.
sudo apt-get install electrum/buster
Selected version '3.1.3-1' (Debian:testing [all]) for 'electrum'
I haven’t come across any issues while using these instructions.
OK, so we don’t need 0brand’s post about EOL then. You should just copy that Qubes text verbatim and insert into Whonix News forum.
whonixcheck page → All fixed
Now going back to link fixes.
@mig5 - I understand you are former OnionShare dev? Would you mind looking over these instructions for accuracy or possible hardening please?
Of interest: AppArmor profile in Whonix works? How? What’s the more secure configuration in the panel options? etc.
Not former but current core dev alongside Micah.
The docs look pretty good. A couple of suggestions/notes however:
Consider not mentioning the current version 1.3, or any other version. You’re only making work for yourself trying to keep the docs up to date (i.e every time OnionShare gets a new release). May as well not mention version, and make your life easier. Case in point: v.1.3.1 is the latest version.
Likewise for step 6 where you list the dependencies to install. We already have that in the BUILD.md of the onionshare repo. Maybe there’s a nice way to say ‘please run the apt-get commands seen in the ‘Debian-like distros’ section of the BUILD.md in the OnionShare repo’, so that if we change dependencies, you don’t have to update obsolete documentation.
Nothing you can really do about this right now, but there’s an unfortunate bug in the OnionShare ‘develop’ branch (which is the default branch) , which causes the app to crash when opening the Settings dialog. Therefore, the step where you edit settings to set the Tor connection method to ‘via control socket’, crashes. This is obviously only a temporary issue until Micah merges in a fix that’s been sitting in the queue for ages, but I can’t force him to, and we have a workflow whereby we review each other’s patches.
As a temporary workaround, you could consider either telling the user to checkout the ‘master’ branch, or, as I did in my testing just now, the latest release tag (v1.3.1 - yes I realise this then re-introduces the issue in my point 1 above, about hardcoding release numbers into your docs).
- The note ‘Check “Create stealth onion services” to make OnionShare operations more secure.’ is a bit too brief: it should be noted that enabling Stealth also requires action from the user fetching the files, in that they need to edit their torrc (Stealth just means ‘onion service Client Auth’.) We already have this documented, so again, you could maybe append "Note, however, that using Stealth mode makes it harder for the end user to connect to the share, because it requires them to edit their torrc. Please see the official documentation at Stealth Onion Services · onionshare/onionshare Wiki · GitHub for more information’
Suffice to say the instructions otherwise worked for me.
The AppArmor profiles probably won’t work against the recent releases or against the develop/master branches of the git repo. They are super old. The contributor who has unofficially maintained/provided our AppArmor profiles has even opened a ticket saying they are out of date and need to be replaced: AppArmor profiles are outdated · Issue #686 · onionshare/onionshare · GitHub
We are hoping to get new AppArmor profiles from them ‘soon’. Not sure how to portray this in your docs, but for now I would not try AppArmor with OnionShare unless you are good at AppArmor profiles, and maybe if so, you can help contribute fixes via the above ticket.
As above - the only real element that currently adds extra security is Stealth mode (ClientAuth).
An additional method to reduce the risk of onion service discovery attacks is to use the Shutdown Timer setting. This allows you to self-destruct the share if no-one came and downloaded your share within an acceptable time window.
Unsetting ‘Stop sharing after first download’ is also obviously a risk as it will keep the share open after someone downloads the file (but obviously useful for sharing to multiple users or long term shares). Likewise Persistent mode is a risk as it re-uses the Onion address instead of a random one each time.
Again, I wouldn’t bother pointing any of this out, as it’s all documented in the OnionShare wiki already. Point any ‘using OnionShare’ advice to the official docs to save yourself effort. The Whonix wiki page should only show Whonix-specific steps required to install or configure OnionShare.
Hope this helps
Microcode needs to be installed on the host.
- Not the default in Linux, Debian?
dpkg -l | grep microcode
- Default in Qubes? dom0:
dnf list | grep microcode
Thanks mig5. All very sane advice.
@0brand - I nitpicked your EOL announcement. Hope that’s okay (good job BTW )
Small nitpick: ARM is less affected and the processor in the rpi is not affected at all. In case your processor is affected you should always install patches on the host/bare metal.
I didn’t add that to that Firmware section. You want those steps there somewhere?
And not widely known in community / explained in wiki (much). Hence why Xen only has low 100s in identified bugs, where Linux / Microsoft is through the roof. Will note & add that link to microkernel research i.e. you’re screwed on normal Linux platform by comparison.
Yet another reason to run Qubes, and have a small target at the core of your system.
I didn’t add that to that Firmware section. You want those steps there somewhere?
In firmware section and linked to it from related places.
sudo apt-get install -t stretch-backports linux-image-amd64 linux-headers-amd64
Do we have this documented somewhere?
No not documented for the kernel.
Updated Electrum documenation
Unfortunately when taking screenshots for electrum the screen would not shrink to a smaller size. Only during configuration though. Had to use larger size screenshots than normally would have.
I’ll work on this then I’d like to complete the Qubes/DispVM TODO’s
torjunkie, I’m working on those flash screenshots to. Actually already have them but the information would not fit on one screen. (large gap between information) Trying to neatly cut and paste both screenshots together.
Patrick, I can start experimenting with:
electrum! Yes! Could you please notify the forum discussion threads?
update vs upgrade - definition - meaning suggesting and finding consensus among what update means, what upgrade means. Like word reference.