Updated Onionizing repositories chapter. I left instructions to revert to http:// URI repositories. Might be a good idea to have for a little while. Less support requests.
Onionizing Repositories - Whonix is also looking at it from the wrong side. Users aren’t looking to onionizing Qubes,Whonix, Debian or Fedora packages. They’ll either want to onionize their Whonix templates or any other template as much as possible or un-onionize it due to issues.
Users usually often are not aware what repositories their templates are using. So would be good to make that page focused on the operating system plain, non-Qubes Debian, Non-Qubes-Whonix or templates debian-9, fedora, whonix; and dom0.
Also, not sure if realistic, cool would be an onionizer software tool. Looking for clearnet repositories and replacing them with onions and vice versa. Then documentation and manual steps could be greatly simplified.
So to clarify (resolve the impasse), how about we add (you can add your math skills to calculate actual % if you like as an example):
Some users question why a different Tor guard is not configured for each identity within a specfic domain of activity, such as email accounts ‘Jane Doe’ and ‘John Doe’. Mathematically speaking, each “roll of the dice” (new Tor entry guard selection) increases the probability that a malicious, adversary-controlled guard is selected. Therefore, it is objectively safer to use one guard with different workstations for each identity, even though this comes with the (low) risk that a compromised guard is chosen for select activities and accounts.
Can we approve that Anon Connection Wizard edit on that page too please (still points to old software).
Thinking about that Tor attacks stuff (Warning page, 16/17 March), why not create a page called “Speculative Tor Attacks” or similar? That way the title suggests we don’t vouch for it, but it at least highlights that there is a lot more than confirmation attacks to worry about (in theory).
The math here is above my pay grade and it was a computer scientist who gave them. I don’t think user docs are a good place to debate matters. It should be a source of concise and authoritative info. If there are questions they are best asked to the professionals.
I am confident I understood his recommendations correctly and translated them into an opsec procedure. Original messages are referenced on there BTW. See if you have a different interpretation.
It’s good but shouldn’t we call this a waterhole attack? Supply chain implies physical tampering like product interdiction or infiltrators in the hardware industry that slip malicious circuitry into a chip fab. Both attack classes are not mutually exclusive.
It’s important to say that the more widespread the targets, the easier detection becomes so sometimes it will be limited to a small number of shipments going to targets.
Based on the preceding information and links, users seeking an open-source solution need to make a compromise. Since RISC processors supporting a fully-fledged operating system do not yet exist
RISC as in RISC-V? RISC-V is an open source, permissively licensed ISA (instruction set). It is not a processor itself. LowRISC is the foundation committed to releasing a version of the processor that is completely open from the ground up.
OpenPOWER technology and opensource hardware principles. Unfortunately it is not compatible with Qubes OS.
I’d add: but it is with Linux. There can be a hypothetical Whonix KVM Version for a Raptor workstation.
Question: Is OpenPOWER merely source available or can foundation members freely modify and release processors based on remixes of the ISA? The word open would be confusing in such a situation.
Contributors and Authorship - should we add e-mail addresses, link to major accounts (like github), and gpg keys there? (Only for those who wish. No need to complete for completeness sake.)