Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If you use deno you can consume dependencies much more securely from arbitrary URLs, such as your own. You can also set permissions for the runtime, though that might not save you depending on the severity of exploits.

Arguably the safest approach is to embed all dependencies in your source, and vet all of them for each release. But I'm glad deno lets me choose which registry I use.

Bun also allows for this but it feels a bit more tacked-on and less like an early architectural decision based around security concerns.



> If you use deno you can consume dependencies much more securely

How would Deno have prevented the RCE issue with React+Next.js?


It wouldn't. I was responding to your concerns about the TypeScript ecosystem more generally.

You avoid the RCE by recognizing that React—and more recently Vercel's—management is a bit of a tire fire, and you should choose better tools with more responsible maintainers.

Part of what bothers me about this situation is that React appears to be a view library, and to many people using it that is what it functions as... But it's now a framework which extends well beyond the browser and entails all kinds of security risks that aren't intuitive at a glance, at all. A lot of people using Next probably have no idea about the security implications of the framework or how React fits into them. It's a mess.

Deno definitely can't fix that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: