At companies like my former employer, developers were given the power and responsibility to vet their own tools. Despite somewhat strict compliance needs we were able to allow junior developers to customize their own IDEs and plugins, since personalization is crucial for productivity. One of those compliance needs was, crucially, that _source code in its full form must not leave the developer's machine except en route to the git repo._
We were comfortable with this posture because the Atom/Sublime/VSCode plugin ecosystem has largely been dominated by honest OSS projects, especially the most popular ones. Thanks, Kite, for ruining that for everyone. I will now personally vet every plugin that my junior devs install from here out thanks to your example.
This problem applies not only to editor plugins but all sorts of things nowadays: npm packages for Node.js devs in particular seem like a great way to get viruses, given how hundreds of dependencies get pulled in, sometimes to save 2 or 3 lines of code. Here is an example in the Node package for Postmark (an email service provider) which had a dependency for literally 4 lines of code:
https://github.com/wildbit/postmark.js/pull/14/files
As developers, we need to be willing to reinvent the wheel when needed, instead of blindly installing dozens of 3rd party packages. And we should vet things we install no matter what.
Comments
At companies like my former employer, developers were given the power and responsibility to vet their own tools. Despite somewhat strict compliance needs we were able to allow junior developers to customize their own IDEs and plugins, since personalization is crucial for productivity. One of those compliance needs was, crucially, that _source code in its full form must not leave the developer's machine except en route to the git repo._
We were comfortable with this posture because the Atom/Sublime/VSCode plugin ecosystem has largely been dominated by honest OSS projects, especially the most popular ones. Thanks, Kite, for ruining that for everyone. I will now personally vet every plugin that my junior devs install from here out thanks to your example.
We've seen it happen before though: http://www.infoworld.com/article/2929732/open-source-softwar...
This problem applies not only to editor plugins but all sorts of things nowadays: npm packages for Node.js devs in particular seem like a great way to get viruses, given how hundreds of dependencies get pulled in, sometimes to save 2 or 3 lines of code. Here is an example in the Node package for Postmark (an email service provider) which had a dependency for literally 4 lines of code: https://github.com/wildbit/postmark.js/pull/14/files
As developers, we need to be willing to reinvent the wheel when needed, instead of blindly installing dozens of 3rd party packages. And we should vet things we install no matter what.
to be fair with that specific example, they changed from a purpose-built function, to a shell call including (albeit extremely simple) text parsing.
I'd generally prefer not to have the git(1) incantation hanging around in an unrelated function.
The dependency "git-rev" uses a shell-call too, so this PR doesn't change much apart from removing the dependency itself.
Here's the original code from the "git-rev" package: https://github.com/tblobaum/git-rev/blob/master/index.js