oxeo0/opsec-blogposts
1
0
Fork 0
mirror of http://git.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd.onion/nihilist/opsec-blogposts.git synced 2025-05-16 21:37:05 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

updated

Browse source
This commit is contained in:
nihilist 2025-05-07 09:12:05 +02:00
parent 9c49c6bef5
commit 341c24852e
9 changed files with 17 additions and 107 deletions
Download patch file Download diff file Expand all files Collapse all files

2
contribute/index.md
View file

@ -70,7 +70,7 @@ _Disclaimer:_ if you're not used to writing technical stuff, please aim for the
Here are the list of things that are offtopic, and that we will NOT cover in the blog (for the foreseeable future at least):
1) _General security and hacking:_ (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 [Hacking section](../../HTB/index.md). 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. **Trying to protect against the threat you don't know about (0days) IS a pointless and futile endeavor.** You can reduce the risks of 0days by going for ultra-minimalism, but we'll leave that at the discretion of the viewers. **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.** We will consider some FOSS software as suitable for opsec use _until proven otherwise (so don't bring up the 0day excuse)_ , not the other way around.
1) _General security and hacking:_ (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 [Hacking section](../../hacking/index.md). 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. **Trying to protect against the threat you don't know about (0days) IS a pointless and futile endeavor.** You can reduce the risks of 0days by going for ultra-minimalism, but we'll leave that at the discretion of the viewers. **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.** We will consider some FOSS software as suitable for opsec use _until proven otherwise (so don't bring up the 0day excuse)_ , not the other way around.
![](65.png)