Comment by montroser
2 days ago
I agree with much of what you said here, but is it really just about the package manager? If I had specified this repo's git url with a specific version number or sha directly in my package.json, the outcome would be just about the same. And so that's not really an end-run around version control at that point. Even with npm out of the picture the problem is still there.
> If I had specified this repo's git url with a specific version number or sha directly in my package.json[…] that's not really an end-run around version control at that point
Yes it is. Git doesn't operate based on package.json.
You're still trying to devise a scheme where, instead of Git tracking the source code of what you're building and deploying and/or turning into a release, you're excluding parts of that content from Git's purview. That's doing an end-run around the VCS.
It's hardly an end-run around VCS to specify an external dependency's VCS sha, and resolve that at build time.
But okay, let's go further and use git submodules so that package.json is out of the picture. Even in that case we have the same problem.
Or, let's go even further and vendor the dependency so it is now copied into our source code. Even in that case too, we still have the same problem.
The dependency has been malicious all along, so if we use it in any way the game is already over.
> It's hardly an end-run around VCS to specify an external dependency's VCS sha, and resolve that at build time
Not "hardly". That's very literally an end-run around the VCS.
This is not a productive discussion.
3 replies →
The root problem is the OS allows npm packages to grab your WhatsApp messages without the user knowing.
The OS isn't allowing anything as far as I can see. It's a fork of a library that allows you to use the WhatsApp API, it actually works, it also just happen to also harvest your credentials and messages.
Should the OS prevent you from doing API calls to WhatsApps servers? What about the actual library this is based on, should that be blocked as well?
The root of the problem is that users and developers may have legitimate reasons to want API access to a service, like WhatsApp. That just comes with a level of risk. Especially in a world where we're not use to auditing our dependencies. The only sort of maybe solution I can see is the operating system prompting you when an application want's to make an outgoing request, but in this case the messages might just go to AWS and an S3 bucket, or it could send them via WhatsApp to the attack, how would you spot that in the operating system, without built in knowledge of WhatsApp specifically?
This is an npm package that allows you to interact with WhatsApp using their API. The OS wouldn’t prevent this as it’s not interacting with your WhatsApp on your machine, but rather logging you in via a skillfully made 3rd party interface, that unfortunately happens to also be evil.