Btw this issue tracker is being phased out:
https://www.whonix.org/wiki/Reporting_Bugs#Issue_Tracker

I am not sure sdwdate-gui would be a strong enough notification if networking was actually blocked if sdwdate did not succeed yet.

This was implemented. Now using python3 requests.

No longer required. Was implemented through te_pe_tb_check enhancements.

https://gitlab.com/whonix/qubes-whonix/-/commit/53ff72ab6ce59cb2c98401fd701ae782ca100e37

I've found why sudo asked for password, it wasn't related to security-misc script mentioned earlier. And should be fixed in newer qubes-core-agent package.

In T1001#20201, @Patrick wrote:

/usr/lib/qubes-whonix/init/torified-updates-proxy-check is currently only started by /lib/systemd/system/qubes-whonix-torified-updates-proxy-check.service.

Wondering why this is happening. When root uses sudo, pam shouldn't even be involved.

/usr/lib/qubes-whonix/init/torified-updates-proxy-check is currently only started by /lib/systemd/system/qubes-whonix-torified-updates-proxy-check.service.

documented here:
https://www.whonix.org/wiki/Whonixcheck_Hardening#Prevent_Downloading_Whonix_.E2.84.A2_News_and_Whonix_.E2.84.A2_User_Census_Counting

Looks all good and quite in Whonix 15.0.1.5.1.

We don't use this tracker for new feature requests anymore either as per:
https://www.whonix.org/wiki/Reporting_Bugs

It is important to understand, that systemD is actually much more than simply an init system:

Shipping kloak in Whonix stable for a few releases already.

After running a bunch of tcp ping tests, the conclusion is this attack
is not really effective against TCP like ICMP. The latency is much lower
for TCP pings and though it slightly decreases with cpu stress it is not
consistent. Reloading pages in TBB with cpu stress
on/off does not impact latency readings while doing so with tc
attached has massive latency foot prints - implying it will ironically make such attacks much easier in addition to degrading performance.

Cyrus recommends adding delays per packet to disrupt inter-packet patterns that remain. The command can be fine tuned as such:

The good news is I think I've figured out the equivalent tc-netem command looking the slot parameter in the manual:

Building on anything other than Debian buster is unsupported.

553 Unable to store creds for

Did you set ClientOnionAuthDir in torrc (to a directory with "private
enough" permissions)?

Rusty

A few more questions:

Btw, Devuan is almost the same Debian with systemD removed from it.
Devuan even uses the same Debian binary repository with a few substitutions/replacements by its own Devuan packages just to eliminate nasty systemD.

In T998#20144, @sanyo wrote:

May I know, what do you think about Whonix vs OpenBSD in terms of security for a headless server without any GUI?

May I know, what do you think about Whonix vs OpenBSD in terms of security for a headless server without any GUI?

I guess it shall not be any harder to port Whonix to Devuan than porting it to original Debian.

There's no manual.

Thanks for the report.

More useful information from my tests: When I setup obfs4 using the Anon-Connection-Wizard the previous obfs4 that I used worked fine. Unfortunately I can't setup snowflake from it.

Don't know if this is indicative of anything but after I add -log snowflake-client.log -log-to-state-dir at the end of the ClientTransportPlugin snowflake line in /usr/local/etc/torrc.d/50_user.conf I obtain the following error:

Tor Browser onion authentication prompt:
https://blog.torproject.org/sites/default/files/inline-images/onion-auth%402x.png

What Tor related apps are broken without support for this?

Alternative to github.com now needed.

Maybe this is bound per connection similar to ephemeral Tor onion services? In that case, other VMs couldn't re-use it.

https://github.com/adrelanos/anon-gw-anonymizer-config/commit/97ff68a6c49ecef3e79ab10e1a930a4f5e13198d#commitcomment-39671373

onion_client_auth_add Flags=Permanent fails with 553 Unable to store creds for