I was wondering to split-out the Tor bootstrap test of whonixcheck. Make it standalone. (Perhaps later called by whonixcheck.) Had some ideas about whonixcheck long term anyhow. There are too many mixed up use cases, see:
And no longer fetching anything from remotes unless whonixcheck is started in a specific mode. (Skipping Tor socks port, Tor trans port [and stream isolation] tests. For better security. [A sane exception for the operating system updates check that just uses apt-get.] At this stage, we no longer need to keep running the leak tests for everyone all the time.
I was also wondering to abolish whonixcheck Whonix News. Info on whonixcheck Whonix News:
On one hand, the notification if a Whonix build version had to be deprecated - lets hope this will never happen - but it may happen - is useful. The other news about important things, I am not sure an info line in whonixcheck is an effective means to communicate that. That would require a much better standalone gui notification.
We could also if ever needed to deprecate a build version by releasing a whonixcheck Debian package upgrade and issuing a big warning popup. The advantage of having whonixcheck Whonix News not go through apt-get applies to a much lesser degree since now everything is hosted on whonix.org and since there is no Permanent Takedown Attack Defender on the horizon anyhow.
Linux distributions have no mechanism to effectively relay important informations to users. By default I would propose an emergency new notification. Lots and lots of Linux desktop users do not continuously follow Linux or their distribution news. Should anything really bad happen such as “debian.org domain down, you will no longer receive upgrades, make sure to read more at …” or “apt-get vulnerability in the wild, do not upgrade using apt-get or you will become infected, read more …”, then I would imagine a non-intrusive “distribution news” popup with this news would be useful with buttons such as “got it, remind me later”. I tried to provide such a mechanism using whonixcheck Whonix News but the gui is much too bad for this to be an effective means of spreading the news.
+1 to that[quote=“Patrick, post:1, topic:2456”]
Maybe only auto running in silent mode and only reporting grave issues. No default active info popups anymore after boot anymore. Silent mode, see:
[/quote]
Maybe this could be chosen by the user in the First-Time-Setup (as Whonix/check Verbosity Setting )
I guess its better than nothing , but there should be a standalone gui notification nonetheless (sadly I would also need to teach me gui related stuff)
Yes then Tor bootstrap could be easily reusable for other things should you need to.
Yes a good idea. IMO only prompt the user if there is something serious instead of bomabrding them with alerts - they will become apathetic and possibly annoyed.
+1 Absolutely. Minimizing the outside connections the system prevents unnecessary risks.
Smart to rely on apt so the notification system is at least as secure as it instead of inventing your own. Permanent Takedown attack resistance and apt fail-safes are possible but its a different discussion.
And even when running it as leak test / connectivity test, perhaps IPs should be hidden by default since users tend to post screenshots. I would not know a usable way to re-enable showing the IPs. Command line options and config options are not very usable but perhaps best that can be offered.
More importantly, I have no idea yet how users could start whonixcheck in its different modes. I mean just the general sanity testing that does not connect to external targets (besides operating system updates check using apt-get) vs extended connectivity test / leak test that connects to check.torproject.org. Perhaps two start menu entries.
Maybe hide the IP by default and only show it if a config or a command line option is present.
This sounds sane ,but I always get a bad feeling when stuff gets simplified and the output hidden .
Offtopic:
Btw I know that there was a Thread about Useability or something and Whonix direction , but what is Whonix main Userbase ( Security Geeks or Privacy Newb’s?)
I would think that there is a majority who cares more about security and is ok with the added “workload” and alerts. ( I believe its better to have a alert to much than one missed)
But as a I2P guy I’m used to be a in the minority.
And even when running it as leak test / connectivity test, perhaps IPs should be hidden by default since users tend to post screenshots. I would not know a usable way to re-enable showing the IPs. Command line options and config options are not very usable but perhaps best that can be offered.
That’s a “good thing” because it stops users from shooting themselves in the leg. Assuming those who dig into the commandline have a good/informed reason for doing so.
Perhaps two start menu entries.
whonixcheck
Whonix Leak and extended Connectivity test
It may be helpful if usr/lib/whonixcheck/check_tor_config.bsh every time before tor is reloaded or restarted. Because right now, the reload and restart with systemd though execute the verification against tor configs, they only provide a Tor fails start log, which is not as helpful as this one.
It may be helpful if usr/lib/whonixcheck/check_tor_config.bsh every time before tor is reloaded or restarted. Because right now, the reload and restart with systemd though execute the verification against tor configs, they only provide a Tor fails start log, which is not as helpful as this one.
It’s a cool idea. It could be implemented in ACW? Fits better there?
For systemd we can easily ship a systemd drop-in to call a script before
Tor reload/restart, happy to help with the drop-in.
Or how do users reload/restart Tor? Perhaps information when that fails
should be shown at these places?
There will be the same issue with systemd drop-in as before:
PreExec=tor --verify will be executed before our drop-in detailed report. Therefore, when PreExec=tor --verify fails, our drop-in will never get executed.
Then we need to somehow define a new systemd unit file that always gets reload or restarted when another (Tor) systemd unit file gets restarted or reloaded.
/lib/systemd/system/tor@default.service is already using:
So saybe we can extend /lib/systemd/system/tor.service with ExecStartPre=... systemd unit file drop-in instead.
Btw… The following also stops tor@default.service.
sudo systemctl stop tor.service
Maybe we shouldn’t tell users to engage with sudo systemctl restart tor@default.service directly but use sudo systemctl restart tor.service instead. (And perhaps the .service can be dropped for simplicity.)
