31–40 of 56 posts
Like the projects but not a Show HN, see the guidelines.
it isn't any of these: Off topic: blog posts, sign-up pages, newsletters, lists, and other reading material. Those can't be tried out, so can't be Show HNs. it's not reading material. it's a set of instructions that you can actually try. so i think it fits.
Here is the entire guide you need to protect yourself from supply chain attacks as a software engineer. Pick whichever of these will consume the fewest resources over time: 1. review an existing library and all dependencies, and all security updates to them forever (or ensure someone capable does or did) 2. implement the minimal functions you require on top of the language standard library yourself Yes, this is serio…
Your suggestion is that I should reimplement React from scratch to avoid supply chain attacks. Like an American fab should extract ore locally to prevent shortages.
(And hey, if anyone is looking for people to do this kind of work for their node_modules at very low cost, I’m available right now! `unfrosted_handsaw${107 * 2}@simplelogin.com`)
Edit: too long to paste here, but if you ask ChatGPT it will show you how using a yarnrc file.
This needs to be solved at the language level by defining whitelist-like contexts. Some sort of with MyContext(allow_sys_cmds=false, network=false, read_disk=false): ... I've seen at least a paper trying to bolt-on such a feature on golang but it's way too convoluted. Of course this doesn't solve everything, especially for languages with magic/collateral effects like running logic on module import.
A friend of mine has been working on [1] which is a less computer-sciency solution to the problem for Go modules that doesn't require adding effects to the type system (to be a bit snarky -- good luck getting more type changes into Go, it might take another 3 decades).
Earlier quoted context omitted.
it isn't any of these: Off topic: blog posts, sign-up pages, newsletters, lists, and other reading material. Those can't be tried out, so can't be Show HNs. it's not reading material. it's a set of instructions that you can actually try. so i think it fits.
All tutorials are set of instructions. But tutorial blog posts are not Show HNs. If this was a script, or a tool I could run - yes.
That first recommendation of pinning exact versions of each and every dependency is borderline insane. That's exactly what lockfiles are for. Which are used by default.
See this Stackoverflow thread:
https://stackoverflow.com/questions/45022048/why-does-npm-in...
The top answer has 3 updates to it, and links to 2 github issues, with conflicting information.
One says:
>If you run npm i against that package.json and package-lock.json, the latter will never be updated, even if the package.json would be happy with newer versions.
The other says:
>The module tree described by the package lock is reproduced. This means reproducing the structure described in the file, using the specific files referenced in "resolved" if available, falling back to normal package resolution using "version" if one isn't.
>This holds no longer true since npm 5.1.0, because now the generated module tree is a combined result of both package.json and package-lock.json. (Example: package.json specifies some package with version ^1.1.0; package-lock.json had locked it with version 1.1.4; but actually, the package is already available with version 1.1.9. In this case npm i resolves the package to 1.1.9 and overwrites the lockfile accordingly, hence ignoring the information in the lock file.)
So good luck figuring out what is true, but it seems to also depend on your version of NPM. Also, don't get me started on the presence of an entirely separate command "npm ci", which is supposed to be the one that is reproducible.
Absolute clowns.
Here is the entire guide you need to protect yourself from supply chain attacks as a software engineer. Pick whichever of these will consume the fewest resources over time: 1. review an existing library and all dependencies, and all security updates to them forever (or ensure someone capable does or did) 2. implement the minimal functions you require on top of the language standard library yourself Yes, this is serio…
Advice that you know, or should know, won't and indeed can't be followed isn't serious advice, it's just posturing. "Security engineer" or not, if you stood up in that kick-off meeting and with a straight face proposed that the team spend the first 3 months reviewing React before starting work - you're out, and rightly so. Security and convenience are always in tension, but there is usually a productive, "sweet spot"…
Personally I would like to see more awareness around the dangers of blindly trusting compiled javascript (and non-human-readable code generally).
That first recommendation of pinning exact versions of each and every dependency is borderline insane. That's exactly what lockfiles are for. Which are used by default.
To be honest, NPM is a complete shitshow when it comes to this, and I wish each and every single person who had a hand in developing it have their keyboards taken away, and never be allowed to touch any developer tooling ever again. See this Stackoverflow thread: https://stackoverflow.com/questions/45022048/why-does-npm-in... The top answer has 3 updates to it, and links to 2 github issues, with conflicting informati…