Long Wiki Edits Thread



Page moved:

New page:

How do you like that documentation style?


Paraphrasing a user question “I didn’t update for a while and I wouldn’t update before enabling that feature but I don’t have that feature installed yet.”

But that’s not what that feature was supposed to communicate.

It’s okay. The information is good, but in terms of formatting - a lot of bullet points in succession I generally try to avoid. I prefer tables in that case for neater formatting.

1 Like

Undocumented, Untested or Unsupported Features could use some more friendly rewording:


The unsupported label Undocumented, Untested or Unsupported Features is insufficient in some cases. It says:

This feature is either undocumented, untested, or unsupported. Please help us implement this feature by becoming a contributor.

Consider Free Support Principle.

It might be possible to get this feature implemented, documented, tested and/or supported by purchasing Professional Support.

Could use a stronger label declined. Or is there any better term than declined?

For example a user asked for VMware support. Then unsupported was misleading since the user asked for professional support which after consideration I wasn’t interested in either. Due to Whonix ™ Policy On Non-Freedom Software it’s not a good direction to spend any time on.


This feature is declined. Either it is incompatible with the current project priorities, goals and/or policies.

It is not on the roadmap. It is unlikely ever being on the roadmap.

Any contributions would be refused.

Professional Support is also unavailable.

Rewording suggestions welcome.

Could also use more friendly wording as per Long Wiki Edits Thread - #1974 by Patrick.

Bug Reports, Software Development and Feature Requests

I think you can deprecate this page completely:

Therefore this page is no longer of any use to anybody.

This also suggests this plug-in section is no longer relevant and can also be deprecated:

1 Like

Browser plugins are still a thing unfortunately.

For example widevine for Firefox.

Or this.

Or widevine for Chrome / Chromium.

It’s more about illustrating a general point than anything specific. Any ideas?

Could you review Hardware Threat Minimization: Difference between revisions - Whonix please? @HulaHoop

1 Like

Good coverage overall.

Lots of debate about China tainting supermicro, but the second story that came out recently shows that LE acknowledges it is real.
One bit of advice we can give is to avoid devices from PRC OEMs.

I would like to avoid Template:Community Support - Whonix at the very top of any page. Maybe a smaller box on the right side only would be more suitable. Perhaps below the thumbnail?
Reason: if Template:Community_Support is on the very top of any page, search engines might pick that up and add it to search engine results. Resulting in non-ideal descriptions of pages. There very top of the page is crucial. It’s best to have short, catchy, concise, well written introductions there because likely search engines use these snippets internally or in search results.

I consider Template:Community_Support to be metatada. It doesn’t mean “don’t even try”. Just attempting to manage user expectations, not setting them too high to be then disappointed.

Please use template {{Whonix}} sparingly. {{Whonix}} and {{Kicksecure}} is supposed to be used in places where it’s really Whonix or really Kicksecure. Not a variable. {{project name}} is a handy variable to allow forks to change the project name. It also simplifies Kicksecure wiki on kicksecure.com (still a lot work to do) importing documentation from Whonix (to be rewritten for Kicksecure) or later keeping in sync, copy/paste.

Ah okay - got it.

1 Like

We could probably reference this somewhere. Dev documentation? I guess the risk is the same for Whonix as OSS (but simple compared to the Linux kernel).

PS did you see that Codedev hack that affected tons of Github projects?

On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits

Abstract — Open source software (OSS) has thrived since the forming of Open Source Initiative in 1998. A prominent example is the Linux kernel, which has been used by numerous major software vendors and empowering billions of devices. The higher availability and lower costs of OSS boost its adoption, while its openness and flexibility enable quicker innovation. More importantly, the OSS development approach is believed to produce more reliable and higher-quality software since it typically has thousands of independent programmers testing and fixing bugs of the software collaboratively.

In this paper, we instead investigate the insecurity of OSS from a critical perspective — the feasibility of stealthily introducing vulnerabilities in OSS via hypocrite commits (i.e. seemingly beneficial commits that in fact introduce other critical issues). The introduced vulnerabilities are critical because they may be stealthily exploited to impact massive devices. We first identify three fundamental reasons that allow hypocrite commits. (1) OSS is open by nature, so anyone from anywhere, including malicious ones, can submit patches. (2) Due to the overwhelming patches and performance issues, it is impractical for maintainers to accept preventive patches for “immature vulnerabilities”. (3) OSS like the Linux kernel is extremely complex, so the patch-review process often misses introduced vulnerabilities that involve complicated semantics and contexts. We then systematically study hypocrite commits, including identifying immature vulnerabilities and potential vulnerability-introducing minor patches. We also identify multiple factors that can increase the stealthiness of hypocrite commits and render the patch-review process less effective.

As proof of concept, we take the Linux kernel as target OSS and safely demonstrate that it is practical for a malicious committer to introduce use-after-free bugs. Furthermore, we systematically measure and characterize the capabilities and opportunities of a malicious committer. At last, to improve the security of OSS, we propose mitigations against hypocrite commits, such as updating the code of conduct for OSS and developing tools for patch testing and verification.

No, didn’t notice.

Not used by Whonix. Even if it was used, it wouldn’t affect the security of Whonix.
Also on CI service Travis CI are no secrets. All the CI gets is access to data already available to the public such as source code and packages. No signing keys / secrets ever uploaded there. No upload access to Whonix website, source code, anything.


“Open Source Misses The Point” can be added to more like saying this is not why free software created at the first place.


A post was split to a new topic: macvk/dnsleaktest

If you like to add more onion v3 links, could you use a wiki template please so we don’t have to write this long address literally multiple times (and increasing chances of typo)? (Simplify maintenance.) Or easier to replicate literally?

Checking the kicksecure-debian wiki here:


There are some improvements can be added:

The following commands need to be run either by root or use sudo.

If running addgroup --system console after su it will give command not found, It will only work if its used with sudo

so the commands should be changed to:

sudo addgroup --system console

sudo adduser user console

sudo adduser user sudo

--no-install-recommends asaik its only used once after apt install, If so the following command has extra --no-install-recommends

sudo apt-get install --no-install-recommends curl gpg gpg-agent --no-install-recommends

And repeated as well in “Pick A Package” Section

sudo apt-get install --no-install-recommends --no-install-recommends kicksecure-cli

Secbrowser is deprecated so this line should be deleted:

kicksecure-xfce: Same as kicksecure-cli but installs the XFCE graphical desktop environment and default applications such as SecBrowser ™ (A Security-hardened, Non-anonymous Browser).

I saw as well this place in the forum:

So which you see my post fits to go as a comment under you can shift my post to.

1 Like