commit: 47b81b9e1411d895b860129150f4861f483f167e
parent da421ee93acb0b81a455cb9ab904ce70c9e6d469
Author: Haelwenn (lanodan) Monnier <contact@hacktivis.me>
Date: Thu, 29 Apr 2021 01:33:38 +0200
notes/computing-truths: Title, turing-machine, machine-sharing, replacements, email
Diffstat:
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/notes/computing-truths.txt b/notes/computing-truths.txt
@@ -1,3 +1,6 @@
+
+ Computing Tips/Truths
+
This is inspired by some "CS Falsehoods" that you can find over the internet[1].
As I do not like having to invert everything I prefer to use truths directly instead, I believe it is more readable this way, at least it makes it easier for me to describe the issues.
I would love to be proved wrong or shown doubts on any of this, thanks a lot if you do.
@@ -9,8 +12,8 @@ I would love to be proved wrong or shown doubts on any of this, thanks a lot if
- You cannot detect for all programs if they will or will not end ("The halting problem")
- Most programs can be made to crash (and under most Operating Systems it's All)
- You can render an operating system unusable (Denial-of-Service) probably more easily than you think, even with some restrictions:
- - Easy to fix: Ping of Death, …
- - Hard to fix: Forkbomb, using up all memory, using up all of a filesystem (be careful with logs), eating the limit of file descriptors/PIDs/… of the current user or root, …
+ - Fixed: Ping of Death, most but not all security issues, …
+ - Mitigated: Forkbombs, using up all memory, using up all of a filesystem (be careful with logs), eating the limit of file descriptors/PIDs/… of the current user or root, …
- Cryptography isn't some magic fairy dust to make something secure (it can actually make it worse)
- There is no magic solutions to make something secure, but there is good practices
- You will need actual debugging tools (gdb/lldb, dtrace, ping, tcpdump/wireshark, …), learn them
@@ -25,11 +28,16 @@ I would love to be proved wrong or shown doubts on any of this, thanks a lot if
- A version number isn't a good indicator of quality
- Data decays eternally
- You need threat models for your security
+- You do not have a turing machine: RAM is finite, memory allocation can fail
+- Your programs aren't alone, try to be a good neighbor
+- Always online isn't
+- Serverless/Passwordless isn't (also define things by what they are)
+- Working Replacements aren't (in)direct extensions of what they replace
## Unique IDs
So called "Unique IDs" aren't always unique:
- A lot of "Unique IDs" can be spoofed or badly generated/stored (quite common for MAC Addresses)
-- If you count all IDs sequentially it means that you end up with enumeration and a lack of plausible-deniability and can lead to uniqueness issues if you restore storage from an previous point in time, this should be strongly avoided in internet applications
+- If you assign IDs sequentially it means that you end up with enumeration and a lack of plausible-deniability and can lead to uniqueness issues if you restore storage from an previous point in time, this should be strongly avoided in internet applications
- In the case of UUIDs, they can be reasonably trusted but be careful on how you use them:
- "nil" UUID (entirely zero) is valid
- version 1 should be avoided in settings where time isn't linear (can easily jump backwards, always at the same date on boot, …)
@@ -47,12 +55,16 @@ So called "Unique IDs" aren't always unique:
## Parsing
- You cannot parse non-regular languages/formats with one regex
-- You cannot entirely validate an email address prior to it's actual usage
+- You cannot validate an email address using one regex (Well, other than `.+`)
+- You cannot validate an email address prior to it's actual usage (ie. UTF-8 might not be supported at destination)
- You cannot write a parser for all version numbers
- Some regex languages aren't (regular)
- You can parse non-regular languages/formats with multiple regexes (see lex/yacc, awk, perl, …)
- You cannot parse human formats reasonably well
- PEMDAS isn't enough to express Math evaluation priorities
+- Client-side input pattern guards aren't a replacement to server-side validators, if you need to pick one, always pick server-side
+- Consider lua patterns instead of some regex dialect
+- Prefer non-backtracking regex dialects (Go/RE2) instead of Perl's dialect
## Unix maintains bugs
- You cannot trust PIDs to point to the same program at two different times (making uptime part of the IDs would help a lot though)
@@ -60,8 +72,8 @@ So called "Unique IDs" aren't always unique:
## Standards
"The nice thing about standards is that you have so many to choose from." — Andrew S. Tanenbaum; Computer Networks, 2nd ed., p. 254.
- POSIX is not followed by most Unix systems (in fact the certifications seems off/wrong)
-- W3C standards first; implementations (maybe) latter
-- 2+ implementations first; description in RFCs latter
+- W3C standards are written first; implementations (maybe) later
+- 2+ implementations first; description in RFCs later
- Most standards aren't enforced or properly certified (even with considering Correctness issues)
## Time
