Ask HN: What are some solutions for ensuring package security?
In light of _another_ NPM worm, I am wondering what can new languages do to avoid such problems. I recall reading somewhere about auditable software supply chains?
2 comments
We may be entering into a new zero trust model for software development; one which for every necessary functionality the safer path includes 'roll your own' and building suites without externalizing the long term support of these functions to third parties.
It's a scary thought, and very much requires intense effort to build reliability from the ground up. In-house, on-premesis and private models will require significant investment (not just infra but also real design and engineering skill-sets) to move away from the 'build it fast and break things' approach.
The days of much work being done by junior programmers in a constant burnout, replace them at-will, lay-off whenever possible mindset which seems to have been the drive behind NPM and the java(script) world for the last several decades may be winding down. Layoff trends in commercial software appear to show ownership's perspective that historic workloads can now be accomplished by a few remaining programmers and an LLM budget.
Using 'Chat-Oriented Programming' (Steve Yegge's term), if done with an effective approach to technical and operational debt, may enable software development teams to absorb the extensive private function library burden. It may be that the potential n-times productivity available through codegen LLM is necessary leverage to provide a supportable silo of in-house functions, and the 'public repository' approach becomes only safe in an environment with isolation between trusted and untrusted-and-thus-disposable instances of features/functions/applications.
These conditions may again require fully staffed development shoppes. Lets hope the reversal happens before the current talent pool is lost to whatever work they find, or before they learn to farm sustainably and lose the desire to sit at a terminal all day.
On thing is certain; we are experiencing some truly interesting history.
It's a scary thought, and very much requires intense effort to build reliability from the ground up. In-house, on-premesis and private models will require significant investment (not just infra but also real design and engineering skill-sets) to move away from the 'build it fast and break things' approach.
The days of much work being done by junior programmers in a constant burnout, replace them at-will, lay-off whenever possible mindset which seems to have been the drive behind NPM and the java(script) world for the last several decades may be winding down. Layoff trends in commercial software appear to show ownership's perspective that historic workloads can now be accomplished by a few remaining programmers and an LLM budget.
Using 'Chat-Oriented Programming' (Steve Yegge's term), if done with an effective approach to technical and operational debt, may enable software development teams to absorb the extensive private function library burden. It may be that the potential n-times productivity available through codegen LLM is necessary leverage to provide a supportable silo of in-house functions, and the 'public repository' approach becomes only safe in an environment with isolation between trusted and untrusted-and-thus-disposable instances of features/functions/applications.
These conditions may again require fully staffed development shoppes. Lets hope the reversal happens before the current talent pool is lost to whatever work they find, or before they learn to farm sustainably and lose the desire to sit at a terminal all day.
On thing is certain; we are experiencing some truly interesting history.
Deterministically build everything from source all the way down without any binaries except for a well documented machine-code seed. Socially audit the code at every layer of the process.
https://bootstrappable.org/ https://reproducible-builds.org/ https://github.com/crev-dev/
https://bootstrappable.org/ https://reproducible-builds.org/ https://github.com/crev-dev/