A collection of (mostly) technical things every software developer should know about - mtdvio/every-programmer-should-know
If you are starting your career and panic reading such list, that would take years to learn, if even. Don't worry.
Most of these items are more like nice to know than should know.
Yeah it would be great if every software developer knew everything. But I doubt even the repository owner know all that is listed.
My best advice to newcomers is get your hands dirty and stay away from endless hours of courses, YouTube videos and "awesome lists".
Absolutely. This kind of list isn't the price to entry.
Toward the middle of your career you should have a reasonable understanding of roughly what's in all of those and why someone cared to write them down, and be able to know when to consult them. And you will know at least a few of them very well.
The repository owner does not know everything, and has already forgotten many things he used to know from the list
But it’s a distilled and curated list of the resources I’ve found important to have at hand and revisit periodically
I'm a little surprised by the answers in "Cryptographic Right Answers". Both libsodium and Chacha20-Poly1305 are not FIPS-compliant. "AES-GCM" is but it has important gotchas in regards to the IV and per key data volume. "AES-GCM-SIV" is more resilient but "AES-GCM-SIV" isn't FIPS compliant either but there is a proposal underway to certify it. So the cryptographic right answer is "it depends". FIPS compliance may not matter to some people but it does a lot to others depending on the context.
I think the safe answer is AES-GCM using envelope encryption?
If you use libsodium, its very hard to screw up your encryption. If you use AES-GCM, it sounds at least like you can screw it up. Surely you'd want to use the first one?
Totally agree with you on this but I think in some settings FIPS-compliance is a requirement -- especially anything to do with the Federal government. The obvious fix is for FIPS to catch up but until then the three choices the document listed aren't great. The first two don't meet the requirements and the last choice, as you've pointed out, can be a bit of a foot gun. I wonder if AES-CBC-HMAC (i.e. Fernet) should be listed as a choice for FIPS? Like keep the original 3 and then have a sub-heading: FIPS-compliant: AES-CBC-HMAC or AES-CTR-HMAC like it did originally.
That list is geared towards developers who don't have a strong background in cryptography and helping them choose a secure algorithm that is easy to implement. Because if you get it wrong, more vulnerabilities will be introduced.
Working around janky compliance standards is a whole separate topic.
:) Soon to be renamed to "a historical collection of things every software developer had to know about."
Will start with "software used to be..."