oxeo0/blog-contributions
1
0
Fork 0
mirror of http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/blog-contributions.git synced 2025-07-02 11:56:40 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

minor fixes

Browse source
This commit is contained in:
nihilist 2025-03-27 19:35:00 +01:00
parent 2733dda9d0
commit 269d350f23
4 changed files with 3 additions and 67 deletions
Download patch file Download diff file Expand all files Collapse all files

2
opsec/contribute/index.html
View file

@ -120,7 +120,7 @@ To be showcased:
<div class="col-lg-8 col-lg-offset-2">
<h2><b>What's Offtopic?</b></h2>
<p>Here are the list of things that are offtopic, and that we will NOT cover in the blog (for the foreseeable future at least):</p>
<p>1) <u>General security and hacking:</u> (making sure a software is secure, how to test if it is secure or not) this is a BOTTOMLESS rabbithole that we won't go into again. I went down that rabbithole myself, in the <a href="../../HTB/index.html">Hacking section</a>. Point being, you anyway cannot defend against the threat that you don't know anything about (0days). You're never going to eliminate all 0day risks by going for ultra minimalism, since every damn line of code your minimal software contains can potentially containa vulnerability. <b>Trying to protect against the threat you don't know about (0days) IS a pointless and futile endeavor.</b> You can reduce the risks of 0days by going for ultra-minimalism, but we'll leave that at the discretion of the viewers. <b>TLDR: Tell the viewer to run the software on it's latest update. If a malicious commit is pushed into the software, don't trust that repository and maintainer anymore, fork it on your own .onion forgejo instance, remove the bad commits, and compile the software yourself.</b> We will consider some FOSS software as suitable for opsec use <u>until proven otherwise (so don't bring up the 0day excuse)</u> , not the other way around.</p>
<p>1) <u>General security and hacking:</u> (making sure a software is secure, how to test if it is secure or not) this is a BOTTOMLESS rabbithole that we won't go into again. I went down that rabbithole myself, in the <a href="../../HTB/index.html">Hacking section</a>. Point being, you anyway cannot defend against the threat that you don't know anything about (0days). You're never going to eliminate all 0day risks by going for ultra minimalism, since every damn line of code your minimal software contains can potentially contain a vulnerability. <b>Trying to protect against the threat you don't know about (0days) IS a pointless and futile endeavor.</b> You can reduce the risks of 0days by going for ultra-minimalism, but we'll leave that at the discretion of the viewers. <b>TLDR: Tell the viewer to run the software on it's latest update. If a malicious commit is pushed into the software, don't trust that repository and maintainer anymore, fork it on your own .onion forgejo instance, remove the bad commits, and compile the software yourself.</b> We will consider some FOSS software as suitable for opsec use <u>until proven otherwise (so don't bring up the 0day excuse)</u> , not the other way around.</p>
<img src="65.png" class="imgRz">
<p>2) <u>Closed-source hardware privacy workarounds:</u> no, we won't recommend to the 90% average joes out there to wire up cables to their CPU in order to disable intel ME, install coreboot, or whatever else, and risk bricking their motherboards/CPUs permanently. <b>We will recommend that average joe to purchase fully open hardware devices, that are free of potential backdoors in the first place, when they are available on the market.</b> We do with the tools at our disposal, so until those tools are made available, we use what we can use. <b>We will consider FOSS Host OS as suitable for privacy, even on closed-source hardware for the time being.</b> (so don't bring up the google pixel graphene OS or the Intel/AMD CPU hardware backdoor argument until you find an actual open hardware alternative that does the job aswell)</p>