I mean even if you blindly copy in the dependency (I'm not saying you should) you've already solved two supply chain issues with install-on-prod:
- dependencies "disappearing" (aka left pad 2, electric boogaloo)
- dependencies running nefarious "install scripts" on prod
Apparently some language package managers also will silently install newer versions than a lock file specifies, if you use the wrong install command. So that's arguably more a case of saving you from yourself but the example I saw said that "... install" is wrong you need to use "... ci" which is kind of asinine IMO.
Things like sudden changes in dependencies should also be noticed more readily.
Copy/pasting source code doesn't solve either of those problems either.
If you already had left pad cached then you were not affected by its disappearance.
If a package needs an install script to be used, to compile some native code for example, you still need to run the install script before you can use the package.
Manually repeating the actions npm does automatically does nothing to protect you from supply chain attacks.
The only thing that helps is to review code before you run it. How the code got to your machine before it was run does not matter.
> If you already had left pad cached then you were not affected by its disappearance.
The evidence of course is that when you say "left pad" no one knows what you're referring to because nothing bad ever happened.
> If a package needs an install script to be used, to compile some native code for example, you still need to run the install script before you can use the package.
This already sounds like a giant red fucking flag, but sure whatever, what you're using needs some compile step. You can be in control of what runs when and where. Heck you could even take the fucking maverick solution and compile the shit once out of band and deploy the compiled binary to your production environment. I know that forethought and planning ahead will come as a fucking shock to the NPM using community, but try it some time, it's really kinda good.
> Manually repeating the actions npm does automatically does nothing to protect you from supply chain attacks.
I mean it does, inherently, if you're running those actions locally in an environment without production access...
Oh noes, your compromised module stole your DB credentials, and your SES credentials to spam all your customers..... and just got a bunch of failures or sent messages to no-one because the environment has dummy data and uses a locked down sending configuration for SES.
There is 100% benefit in running that shit in a development environment.
> The only thing that helps is to review code before you run it.
Right, and somehow you think having the code in question literally in your VCS, waiting for a merge like all the other code... that's not apparently helpful.
But hey thanks for proving me right about the unhinged complaints. Stong echoes of "we've tried nothing and we're all out of ideas".
> There is 100% benefit in running that shit in a development environment.
Most of the recent supply chain attacks specifically target stealing secrets from development environments.
> But hey thanks for proving me right about the unhinged complaints.
I'm sorry if I'm upsetting you, but I am not complaining or trying to provoke you.
"Just check in the dependencies and review them" is not a revolutionary idea. It makes sense in many contexts.
But it is not practical in the overwhelming majority of contexts. React's last minor version bump included 100 files and ~5k changes. It also bumped the versions of 6 direct dependencies, which in turn bumped dependencies, etc.
It is not reasonable for a small (or even medium) team using react to manually review all of the changes and all the changes in react's transitive deps each time they need to update. The problem grows exponentially with all of the other common projects and libraries likely being used in a front end project(vite, react router, redux, vitest, etc).
pick a few non-trivial npm projects and try to audit all of the changes (for all transitive dependencies) for a few releases that bumped dependencies.
I think we may be talking past each other at this point, but secrets from a dev env can be more valuable than secrets from a production env.
With things necessary for a dev env, like read/write access to source control, attackers can get access to internal data, and push malicious code that gets run in a prod env anyway.
If you want to make the claim that using react is an insane indefensible choice from a security standpoint, you are being idealistic at best.
Telling people not to use react does not help anyone, and that type of recommendation causes reputational damage to the security industry.
Access to source control is required on a developer workstation.
It is not required inside an application environment on that workstation (eg a VM or other such system that both provides a standard environment and creates separation)
I'm not making any claims about the security of react.
If I show a person on the street a Fuji apple and a Honeycrisp and ask if they're approximately the same, they're going to say yes even if they're labeled.
Php has had a strict equals operator for decades. You not using it is not a language fault.
For the second point: I doubt you'll fine any language where you can just do an equals comparison on floats and it works as expected. That's the nature of floating point numbers.
If a child is "folded in half" by someone looking at their phone, no one accepts that as "good enough", and there is a direct action: the driver responsible will lose their licence and likely end up in prison. If it happens often enough, laws are changed.
What happens when a Tesla does the same thing? Besides them lying and hiding information I mean. What remedial action is taken to reduce that specific risk from reoccurring?
>If a child is "folded in half" by someone looking at their phone, no one accepts that as "good enough"
But of course we do. Yes, we punish the individual driver that did it, but we still allow humans to drive cars. We accept the fact that driving a car carries sone risks, but we value the convenience of getting to our destination easily more than we value lives of those kids that will get killed from time to time.
Okay, but what about the hundreds of clones of this driver who have identical education, behavior, no sense of individual identity to attribute their actions to separately? Certainly we don't wait for every one of them to kill a child before doing something more drastic than firmly instructing them "killing children is bad!"
> Yes, we punish the individual driver that did it, but we still allow humans to drive cars.
Yes because bad drivers aren't representative of all drivers. You also missed the part where laws are changed, safety laws are strengthened.
Oh wait. You're American aren't you.
In most of the world, laws are put in place to protect people. The Cybertruck for example, cannot be legally driven (regardless of not being for sale) in many countries because it doesn't meet pedestrian safety standards.
In my home state it's a finable offence to touch or even have your phone sitting in your lap while driving a car, and they've put detection cameras in place to enforce these laws.
So maybe define who you mean by "we" before claiming that people think kids being mutilated by negligent drivers of either the robotic or fleshy kind, is "good enough".
> In my home state it's a finable offence to touch or even have your phone sitting in your lap while driving a car, and they've put detection cameras in place to enforce these laws.
If you've all been reduced to vibe coding and hoping for the best I'd suggest that you aren't really participating in the software industry either mate.
If I wanted to spend a lot of time reading the code and figuring out what part actually needs changing, sure... but in this case it's faster to pay for more tokens and get the AI to do it.
For code I wrote, it's typically faster for me to modify it than to get the AI to do it.
True developers don't leak the keys to their sources just because they need convenience-features from a "free IDE with tons of sexy bells and whistles" ..
Features that would, incidentally, be obviated by making just a bit of a better effort to be better managers of the filesystem and ones' source code - and thus: become more competent developers.
There is a limit to the positive impact of convenience features in any tools, not just IDE's. We are seeing that limit being broached with every exfiltration of repo keys attributed to VSCodes' crap anti-user architecture ...
You'll scream at the universe when it happens to you.
Your comment implies that you've somehow misunderstood my comments and thus think that I am using Microsoft's hot garbage text editor with a million plugins.
Your comment came across as sarcasm directed at aa-jv's position that folks are lured into the VSCode abyss and stay there because their comfort level won't let them leave, while VSCode - meanwhile - continues to be a huge security liability for any project where it is used.
... the only sarcasm I posted was about screaming at the universe in response to his suggestion that the only alternative to people loading up a text editor with a million shonky plugins to try and make it an IDE, is to eschew all IDEs.
The sarcasm was because this suggestion is ridiculous IMO. It's like saying "Tesla refuses to use state-of-the-art LIDAR for their attempts at an autonomous vehicle, therefore I shall only travel in vehicles that have both a driver and a conductor, and are propelled by beasts!".
VSCode being a turd isn't a reason not to use an IDE. It's a reason to use an actual IDE, rather than a glorified text editor, with the aforementioned millions of shonky plugins trying to recreate IDE levels of functionality.
Well your point didn't come across at all, just sayin'.
But here's the point: All IDE's eventually become liabilities as they attempt to become an operating system.
Better to just use a text editor, learn to use the build tools, navigate the filesystem with tools that don't have plugins sourced from external sources, etc.
Of course, if your language and execution environment of choice don't allow this, thats another thing entirely. I know you can't do proper javascript development without an IDE - and that's the issue, actually. You shouldn't need a special editor with bells and whistles to do development, and on that point I agree with you entirely.
How many other languages of any kind have a standard library that is so bizarrely lacking as JS?
Now how many other mainstream languages of any kind have a standard library that is so lacking?
Now how many other mainstream languages have a swathe of front-end developers that suddenly realised they can run code in a CLI or on a server, and spent exactly 0 minutes learning about how to make it not shit?
Now how many other languages get used in scenarios where it makes absolutely zero sense because the developer only knows javascript?
Yes, and it makes no sense. It's not a "swathe of front-end developers" problem.
Developers in general want to push packages. They don't want to experience friction while doing it. They especially don't want to have to do things like engage with Linux distribution maintainers in order to get their packages into official software repositories. They want to just run $pkgr publish on their repo and that's it. So they invariably end up creating their own distribution mechanisms with zero maintainers involved. Just untrusted randoms making accounts and pushing random stuff. It's easy, so naturally what happens is the repositories get filled with software.
It's only natural to use the stuff that is out there, so the packages get added to projects as dependencies despite the fact none of it is even slightly trusted. Developers hate friction when using libraries too. They very much want to just run $pkgr install x on their repositories and be done with it. They don't want to do things like read the source code or verify that it actually corresponds to what they've downloaded. That's somebody else's problem. On Linux distrubutions, that somebody else is the package maintainer, the exact person the programming language package managers aim to eliminate.
> It's only natural to use the stuff that is out there
Sure, if your entire "community" lives and dies by a nonsensical "don't reinvent the wheel, there is a package for that" chant that would rival the most fervent cult members.
That is quite literally the most persistent cargo cult in the entire computing industry. It's the rule, not the exception. Pretty much every community is guilty of it.
Who knew that the killer task for LLMs would be "recreate existing things that exist without me mentioning them by name, based on a worse alternative as the example".
You're seriously suggesting that an electron app you vibe coded in two days is more performant than native code that's been developed and improved and tweaked over literal decades?
Just a word of warning from someone who's always advocated for this approach:
Prepare to be inundated with ridiculous, nonsensical arguments about why it's impossible to work that way.