Long Wiki Edits Thread

A post was split to a new topic: Tor Myths and Misconceptions page

Firefox vs Chromium seems great in theory, but there are a few issues with that:

  • Chrome is non-freedom software → Avoid Non-Freedom Software
  • Chrome is NOT Chromium.
  • The conclusion “use Chromium instead” would have been wrong. See:
1 Like

I think you misunderstood my second point. Since it is on the Tor Myths and Misconceptions page, it is to highlight that any serious adversary would pwn your ass in two seconds flat if they wanted to. Many newbies or common users don’t understand that - so their misconceptions should be shattered.

I didn’t mean to insinuate that Chrome/Chromium is a suitable alternative, or should be run over Tor etc. If you read it that way, all that needs to be added at the bottom is this sentence:

Despite Tor Browser’s various security weaknesses, alternative browsers should not be used in the Whonix platform:

  • this would pose a serious fingerprinting risk
  • users may be vulnerable to critical unpatched vulnerabilities [ref]In recent history remotely exploitable vulnerabilities remained unpatched in Linux repositories for extended periods for alternative browsers (like Chromium).[/ref]
  • proprietary browsers like Chrome are antithetical to privacy
1 Like

Yes, I guess it could be misinterpreted that way.

That sounds good! Please add.

Done.

2 Likes

Page moved:

New page:

How do you like that documentation style?

Background:

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:

Inspiration:

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.

declined:

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.

Suiteable?