[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Release Candidate Whonix 9 ( 8.6.6.7 ) - testers wanted!

[html]

The version number for this testers-only release is 8.6.6.7, which will become Whonix 9 the moment it’s blessed stable.

Download link for Virtual Box images (.ova), experimental kvm /qemu / Qubes images and OpenPGP signatures (.asc):

http://mirror.whonix.de/8.6.6.7

Upgrading Whonix 8 to Whonix 9

– You cannot upgrade using apt-get dist-upgrade or you will break the packaging system!

– You can upgrade using these instructions: https://www.whonix.org/wiki/Upgrading_Whonix_8_to_Whonix_9

If you want to build from source code, see:

https://www.whonix.org/wiki/Dev/Build_Documentation

Thanks to everyone who made this test release possible!

Changlog between 8.6.6.0 and 8.6.6.7:

- whonixcheck, timesync: minor output

– anon-meta-packages: fix, added “Pre-Depends: whonix-legacy” to whonix-gateway and whonix-workstation

– whonix-legacy: clean up old Whonix-Gateway shortcuts

– updated debian stable frozen sources

– makefile: added new feature “make deb-chl-bumpup” – Bump upstream version number in debian/changelog.

– rads: made compatible with systemd / debian testing by adding tty1 autologin drop-in config

– xchat-improved-privacy.postinst: fix, disable XChat plugins by default even if folder /home/user/.xchat2 exists

– libvirt xml files: Enable use of Hardware Assisted Paging if available in the hardware.

– sdwdate: fixed systemd spams syslog due to time changed by sclockadj (fixed #289)

– sdwdate: fix, clean up temporary directory on exit

– uwt: all temporary files are now in /tmp/uwt

– anon-base-files /usr/lib/pre.bsh: all temporary files are now in /tmp/prepost

– whonixcheck, timesync, tb-updater: fix, clean up temporary files/directory

– whonix-repository tool: fix, clean up temporary directory

– control-port-filter: fix, clean up temporary directory

– build script: install whonix-gateway or whonix-workstation meta package respectively

– build script: Use SAS rather than SATA as virtual hard disk controller for VirtualBox hdds to work around a VirtualBox upstream bug that causes filesystem corruption on high disk I/O (https://www.virtualbox.org/ticket/10031). Thanks to @Neurodrive for the bug report (https://github.com/Whonix/Whonix/issues/274).

– whonix-repository tool, anon-shared-build-apt-sources-tpo, anon-apt-sources-list: use wheezy rather than stable as per https://www.whonix.org/forum/index.php/topic,445.msg3640.html

– build script: added –file-system (var: whonix_build_file_system)

– build script: added –hostname (var: whonix_build_hostname)

– build script: added –os-password (var: whonix_build_os_password)

– build script: added –debopt (var: whonix_build_debopt)

– whonixcheck: check_virtualizer, no longer warn if Qubes (https://www.whonix.org/wiki/Qubes) is detected; improved output, improved html tags

– anon-shared-build-apt-sources-tpo: updated The Tor Project’s apt signing key as per https://trac.torproject.org/projects/tor/ticket/12994#comment:9

– build script: fix –terminal-only

– build script: fix –no-default-applications

– whonixcheck: refactoring, use /usr/lib/msgcollector/striphtml rather than sed in usr/lib/whonixcheck/check_tor_socks_or_trans_port

– tb-updater: update tbb version url as per https://trac.torproject.org/projects/tor/ticket/8940#comment:21

– tb-updater: compatibility with new recommended tbb versions format as per https://trac.torproject.org/projects/tor/ticket/8940#comment:28

– anon-ws-disable-stacked-tor: Set environment variable “export TOR_SKIP_CONTROLPORTTEST=1″ to skip TorButton control port verification as per https://trac.torproject.org/projects/tor/ticket/13079. Will take effect as soon as The Tor Project merges the TOR_SKIP_CONTROLPORTTEST patch.

– sdwdate: curl, use –head rather than –include as per https://github.com/Whonix/Whonix/issues/315

– sdwdate: Breaking change: pool variable names were renamed. SDWDATE_POOL_PAL, SDWDATE_POOL_NEUTRAL, are now called SDWDATE_POOL_ONE, SDWDATE_POOL_TWO, SDWDATE_POOL_THREE. If you were using custom pools, you should update your config according to the new variable names. As per https://github.com/Whonix/Whonix/issues/310.

– sdwdate: no longer using pal/neutral/foe pool design. Using three pools instead, that only contain servers of the type “pal”. As per https://github.com/Whonix/Whonix/issues/310. Thanks to https://github.com/HulaHoopWhonix for suggesting it.


[/html]

I’m not sure if there is a bug but on my first 2 gateway boots, whonixcheck did not succeed. It took a long time on first boot for tor circuits to establish, there were no problems with firewall at all.

Then on my third boot I manually run apt-get update and upgrade on terminal and there were no problems. whonixcheck also worked after that. I guess whonixcheck was waiting for apt-get but I’m not sure.

Some suggestions:

  • On first run initializer, the sentence ends with “your system might be unstable”. I suggest “might become unstable”

  • For Whonix or linux beginners in general having a “Update Packages” desktop shortcut on both images to do “sudo apt-get update && sudo apt-get dist-upgrade” automatically, without password would be a huge usability bonus. Is there any problem with this idea? The relevant place on whonixcheck could also be replaced with a shorter text and a link to run this shortcut if possible (if there are available updates). That would look less scary than the current text. The similar thing could be done for whonix apt repository, i.e. providing a direct link on whonixcheck.

Note: If this is a good and possible idea, the apt-get link on whonixcheck should only include “apt-get dist-upgrade” for faster update. Further suggestion, doing this on whonixcheck without a new terminal screen?

  • Please replace the name “Privacy Browser” or “Tor Browser (AnonDist)” with “Tor Browser”. I asked for this several times but asking again. I see no problem leaving the original name untouched, and believe the change to be a result of unnecessary concerns. However for short-term “Browser” or “Internet Browser” would be a less confusing name than “Privacy Browser”

  • Confirm Link Open, I suggest to make the links bold.

  • Klipper history should be cleared on each shutdown. Can we also prevent any clipboard content to be written to disk if that is the case?

  • xxxxxxxxxxh5kyrx.onion/blog/ does not open anymore due to redirection to https

  • Can we avoid duplicate news result on whonixcheck? Currently there are 4 results, 2 of them telling it is up to date, 2 of them telling no news file available yet. Latter is unnecessary.

I suggest trying your best to simplify and minimize the whonixcheck structure and content for better usability. It is currently too long.

  • Please create a ticket dedicated to “speed up whonixcheck”. I think one problem here is the sourceforge apt-get repository, right? It is usually very slow

Runs flawlessly here

[quote=“z, post:2, topic:492”]Some suggestions:
[…]

  • For Whonix or linux beginners in general having a “Update Packages” desktop shortcut on both images to do “sudo apt-get update && sudo apt-get dist-upgrade” automatically, without password would be a huge usability bonus. Is there any problem with this idea?
    […][/quote]

Wouldn’t this be a security risk?

Would like this behavior too.

The only bug(?) i noticed is ‘whonixcheck’ doesn’t recognizes an available update about the package ‘whonixcheck’.

INFO] [whonixcheck] Whonix News Download Result: Installed whonixcheck version 0.4-1 is up to date.

user@host:~$ apt-cache policy whonixcheck 
whonixcheck:
  Installed: 3:0.6-1
  Candidate: 3:0.7-1
  Version table:
     3:0.7-1 0
        500 http://sourceforge.net/projects/whonixdevelopermetafiles/files/internal/ wheezy/main i386 Packages
 *** 3:0.6-1 0
        100 /var/lib/dpkg/status

[quote=“ir1s, post:3, topic:492”][quote author=z link=topic=517.msg4016#msg4016 date=1410745176]
Some suggestions:
[…]

  • For Whonix or linux beginners in general having a “Update Packages” desktop shortcut on both images to do “sudo apt-get update && sudo apt-get dist-upgrade” automatically, without password would be a huge usability bonus. Is there any problem with this idea?
    […][/quote]

Wouldn’t this be a security risk?[/quote]

If done right, no security risk. It’s a nice idea. There are technical challenges (https://www.whonix.org/wiki/Dev/Automatic_Updates#One_click_upgrade_button_for_Debian_packages), therefore unfortunately not on the horizon.

The only bug(?) i noticed is 'whonixcheck' doesn't recognizes an available update about the package 'whonixcheck'.

Indeed a bug. This is a wrong string. It should not say “whonixcheck”, but “whonix-gw-packages-dependencies” or “whonix-ws-packages-dependencies”. Will be fixed in the final. Which is the package it is checking. (There is no “Whonix Debian Package Version” anymore, because the whonix-(gateway|workstation|shared)-files packages have been split into multiple packages. So the “whonix-(gw|ws)-packages-dependencies” is the closest to check until a mechanism to check all packages has been implemented (if ever). But the latter is a separate topic.

Thank you both for your feedback!

No critical bug reports yet, so the probably-final build will be created soon.

Many of these suggestions are more like general suggestions and could go into their own thread so they can be better discussed.

- On first run initializer, the sentence ends with "your system might be unstable". I suggest "might become unstable"
Probably true. Will discuss this with Jason (a native English speaker). And probably do this in Whonix 10.
- For Whonix or linux beginners in general having a "Update Packages" desktop shortcut on both images to do "sudo apt-get update && sudo apt-get dist-upgrade" automatically, without password would be a huge usability bonus. Is there any problem with this idea? The relevant place on whonixcheck could also be replaced with a shorter text and a link to run this shortcut if possible (if there are available updates). That would look less scary than the current text. The similar thing could be done for whonix apt repository, i.e. providing a direct link on whonixcheck.

With the lat sentence you mean a link to Whonix Repository Tool?

- Confirm Link Open, I suggest to make the links bold.
Should be the case already. Just tested it again... It is already is bold for me. Do you have any example link where this isn't the case?
- Klipper history should be cleared on each shutdown. Can we also prevent any clipboard content to be written to disk if that is the case?
I don't think so. We're 0 % amnesic anyway. The only safe thing to prevent local logs would be an amnesic live system.

Related:

- xxxxxxxxxxh5kyrx.onion/blog/ does not open anymore due to redirection to https
Notified fortasse (webmaster).
- Can we avoid duplicate news result on whonixcheck? Currently there are 4 results, 2 of them telling it is up to date, 2 of them telling no news file available yet. Latter is unnecessary.
Will consider this for Whonix 10: https://github.com/Whonix/Whonix/issues/334
- Please create a ticket dedicated to "speed up whonixcheck". I think one problem here is the sourceforge apt-get repository, right? It is usually very slow
It's mostly Whonix's APT Repository, because sourceforge uses redirections, that are not the fastest, I think. Already got a ticket: https://github.com/Whonix/Whonix/issues/178

FYI:

I’ve begun doing --install-to-root builds with this RC 8.6.6.7 version.

I’m likely going to be doing the following build scenarios:

  • Qubes HVM / Debian Wheezy / 32-Bit / Frozen Sources
  • Qubes HVM / Debian Wheezy / 32-Bit / Current Sources
  • Qubes HVM / Debian Wheezy / 64-Bit / Frozen Sources
  • Qubes HVM / Debian Wheezy / 64-Bit / Current Sources
  • Qubes AppVM / Debian Jessie / 64-Bit / Frozen Sources
  • Qubes AppVM / Debian Jessie / 64-Bit / Current Sources

And potentially some builds in VirtualBox along with this.

I could be finished as soon as later tomorrow.

I will of course report any issues that arise.

So far, I’ve done the 32-Bit --install-to-root build scenarios with 8.6.6.7:

  • Qubes HVM / Debian Wheezy / 32-Bit / Frozen Sources / Whonix-Gateway

  • Qubes HVM / Debian Wheezy / 32-Bit / Frozen Sources / Whonix-Workstation

  • Qubes HVM / Debian Wheezy / 32-Bit / Current Sources / Whonix-Gateway

  • Qubes HVM / Debian Wheezy / 32-Bit / Current Sources / Whonix-Workstation

These all successfully built in Qubes, without any errors, using the Debian KDE version:

  • debian-7.6.0-i386-kde-CD-1.iso

The only issue I encountered in Qubes is a whonixcheck error, which seems Qubes-specific, so I will create a new thread about this over in the Qubes forum.

I also did a few attempts at building with --install-to-root in VirtualBox and each time I experienced multiple build errors, which I ignored with “c + enter”. Each time, some differing errors seemed to occur in a VirtualBox build. Inconsistent error results with VirtualBox --install-to-root.

I’m still testing.

Reference:
https://www.whonix.org/forum/index.php/topic,524.msg4038.html

I also did a few attempts at building with --install-to-root in VirtualBox and each time I experienced multiple build errors, which I ignored with "c + enter". Each time, some differing errors seemed to occur in a VirtualBox build. Inconsistent error results with VirtualBox --install-to-root.
Please post them in a new thread in development forum. Why new thread? Probably best to keep this one less technical.
I don't think so. We're 0 % amnesic anyway. The only safe thing to prevent local logs would be an amnesic live system.

Do you believe an all or none approach is a good idea here?

Would you prefer Tor Browser to leave history behind so if the VM is compromised, attackers could easily correlate your activities. Klipper might contain even more critical data, it copies every text selection, not only clipboard data. I’m sure Klipper and its traces is on the list of the first places adversaries will attack/upload if they could compromise a Whonix.

Perhaps search for other alternatives for Klipper?

Or warn users that every text they select or copy is being logged, because this behavior is unexpected and unacceptable, because it is not necessary and preventable

I am afraid this could quickly turn into a rabbit hole, a time sunk that would be better spend on working on an amnesic version of Whonix.

Klipper gets installed as a dependency of kde-workspace. Which makes this more difficult. Otherwise it wouldn’t be installed.

Klipper will not be automatically started anymore in Whonix 10. Thanks for suggesting it.

git:

UPDATE:
https://www.whonix.org/forum/index.php/topic,542.0.html

Whonix 9 has been released:
https://www.whonix.org/forum/index.php/topic,529.msg4093.html

Therefore no more testing of this version required.

Thread locked. Please post separate topics (if there aren’t suitable ones already) for other discussion.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]