[HN Gopher] Open source maintainer pulls the plug on NPM package...
___________________________________________________________________
Open source maintainer pulls the plug on NPM packages colors and
faker, now what
Author : arnon
Score : 179 points
Date : 2022-01-09 21:33 UTC (1 hours ago)
(HTM) web link (snyk.io)
(TXT) w3m dump (snyk.io)
| throwawayay02 wrote:
| > now what
|
| Now pin an older version and if you want fork it and develop it
| yourself. Whooptidoo.
| duxup wrote:
| I get how they feel, but why shaft EVERYONE?
| [deleted]
| cerved wrote:
| because they're leet haxxxor dickwad
| Osmose wrote:
| It's a bit wild that the sum total money spent on salaries for
| engineers handling potential problems stemming from this or
| defending against the possibility in the future could probably
| have covered paying the maintainer a living wage many times over.
| thefourthchime wrote:
| Living wage? haha, more like 100 peoples living wage.
| oblio wrote:
| Tragedy of the commons, shortsightedness and misaligned
| individual incentives.
|
| Individual contributors in large companies, especially, would
| want their companies to fund FOSS projects they use. But
| approval processes are generally extremely complicated and
| there's nothing to gain internally by doing it. And we're
| talking about money that these corporations spend each
| millisecond. They barely need approvals for many other
| activities costing 10x, 100x in other domains.
| Flocular wrote:
| Imagine they introduced something worse. Could any developer
| explain to a manager why you _needed_ to import this package?
| "Why do we need colors there?", "Why can't we make that colored
| ourself?"
| iainmerrick wrote:
| "Why are you writing all this stuff by hand? Isn't there a
| package for that?"
| chrisshroba wrote:
| An easy answer would be "we import thousands of packages either
| directly or recursively, so while we may be able to replicate
| the work of any one of those (which is unlikely to be true in
| the first place), it would take thousands+ of engineer hours to
| replicate all of them, and there was no way of knowing that
| this one among thousands would be sabotaged."
| Beta-7 wrote:
| At my last job we (InfoSec) had the devs fill out "ownership"
| forms for when they want to include something third-party into
| the product. Other than forcing the team to do due diligence on
| the third-party it also made them responsible for keeping it
| secure and them the people "at fault" if something went wrong
| due to it.
|
| While it was seen as an unnecessary hurdle set up by us I hope
| it started some meaningful conversations in the teams and maybe
| even end up with them "reinventing" the wheel for the better.
| commandlinefan wrote:
| > now what
|
| stop trying to save a couple of bucks by reusing functionality
| that's not _that_ hard to just develop in-house maybe?
| notatoad wrote:
| only helps if people developing the functionality that _is_
| difficult to develop in-house do the same. i 'm not going to
| build my own AWS cdk.
| hnthrowaway0315 wrote:
| Do something better -- self host!
|
| Everyone decloud and only use the standard libraries
| compilers provide. What a wonderful world! Everyone is forced
| to do some system programming. Going to be pain in the
| beginning but then whoever really passionate about
| programming (not shipping products but programming) is going
| to be happy.
|
| OK just joke :/ Although I do secretly wish to wake up one
| morning and find out we have to do things like in the early
| 90s.
| notatoad wrote:
| i would pay for a service that runs an NPM mirror of a "last
| known good" version of packages to avoid this kind of thing. just
| keep all my dependencies a few weeks behind NPM to give things
| like this a chance to get caught, and let me continue blindly
| updating.
|
| every time something like this happens, the reaction in the
| comments is the same: well you should test your dependencies. and
| yeah, i do that before release, but running an npm update on my
| dev branch and finding one of my dependencies has broken
| something is a bunch of work i could do without, and seems like
| work that is being duplicated by a ton of developers.
| cerved wrote:
| You're using a VCS I presume? Why not just rollback?
| hnthrowaway0315 wrote:
| Maybe everyone should include a clause in the license to force
| commercial use to pay certain "tribute" e.g. 0.01% of gross
| revenue.
|
| Worst case everyone is going to invent their own wheels, which is
| beneficiary to all lower-echelon programmers (but not so for
| managers/tech leads as they have responsibility to ship things)
| because I as one definitely want to invent as many wheels as
| possible.
| capableweb wrote:
| Doesn't it seem strange that Snyk is creating a vulnerability
| report for this + labeling it a DoS? DoS is something someone
| executes against a target, in this case a package had it's
| functionality (purposefully) altered. That's like calling
| changing the API of a popular library DoS, because now
| application authors need to change their code/use a different
| library...
|
| Fittingly enough, all four solutions for this particular issue
| all goes back to Snyk, as seen in the bottom of the blog post.
| Seems like they are labeling this a DoS to justify being able to
| publish something in their database and blog.
| detaro wrote:
| Introducing a deliberate endless loop is not like changing the
| API of a library, no.
| capableweb wrote:
| But if the API offered a function called .countBy but then
| renamed that function to be .countAllBy, now I can't run my
| application anymore, causing my service to go down if I
| upgrade the version without testing it, is that a DoS now?
| jtvjan wrote:
| NPM expects packages to follow semantic versioning. If a
| package contained a breaking change like that, there would
| be a major version bump, and you'd have to upgrade
| manually.
|
| If the maintainers wasn't acting maliciously, they could
| change this new version to count as a major release, and
| then it wouldn't be a DoS.
| idbehold wrote:
| This change introduced an infinite loop upon import. It is
| nothing like changing an identifier which would've provided
| an error message about where the issue occurred.
| detaro wrote:
| no. is it really that complex of a concept that intent of a
| change matters too, and introducing an endless loop to
| cause trouble to users is different from a legitimate API
| change that does a useful thing?
| capableweb wrote:
| Who are you to decide what is useful/legitimate or not?
| As a user of $ExampleLibrary, I surely know best what's
| useful rather than the maintainer.
| fault1 wrote:
| > Doesn't it seem strange that Snyk is creating a vulnerability
| report for this + labeling it a DoS?
|
| I think it most definitely falls into "malicious code" that
| certainly is not done in good faith, and if not handled
| properly by downstream users, can cause a lot of unexpected
| problematic failures.
|
| Whatever labels are used to characterize this, whether to call
| it a vulnerability/DoS or not, are just a matter of arguing
| over semantic meaning.
| forty wrote:
| I guess most customers of snyk if not all, are going to be
| happy that they tagged this as a vulnerability. I'm not sure
| why they would have done anything differently, seems like
| exactly why they are paid for (I don't use them and have no
| relationship with them)
| trexd wrote:
| Why not just change the license to GPLv3 for the upcoming
| version?
| throw_m239339 wrote:
| GPL for students and open source projects, paid license for
| orgs and companies. GPL itself isn't really a way to get paid
| for your work.
| trexd wrote:
| I was speaking more to preventing companies from using your
| open source work, but I guess in this instance the emphasis
| is on getting paid.
| bastardoperator wrote:
| Should I get paid for my multiple contributions to faker (I don't
| think I should)? I've submitted several PR's for generating data
| all of which were accepted. Even back then the maintainer was
| barking about money...
|
| Honestly the project would be better off forked. He did not write
| this library entirely by himself, at this point I just see him as
| holding other committers contributions as hostage. It's a bad
| look, why would anyone want to deal with him after this stunt is
| beyond me.
| detaro wrote:
| prev: https://news.ycombinator.com/item?id=29863672
| maxclark wrote:
| What's the fix here?
|
| Maintainers should be able to do whatever they want either their
| code
|
| But if they vandalize their modules that should be a lifetime ban
| from the registry
|
| It's pretty obvious that node needs a better method for dealing
| with this by now
| hartator wrote:
| Anyone knows what the author meant by the "LIBERTY LIBERTY
| LIBERTY" message?
|
| It's unclear if it's referring to current authoritarian turns in
| our western world, big corps using his software for free, or
| something else.
| fault1 wrote:
| The author of this package was caught with 50lbs of Potassium
| Nitrate (in the middle of NYC) and a bunch of materials on
| making bombs and booby traps when his apartment caught fire:
|
| https://abc7ny.com/suspicious-package-queens-astoria-fire/64...
|
| https://www.qgazette.com/articles/more-charges-possible-for-...
|
| https://nypost.com/2020/09/16/resident-of-nyc-home-with-susp...
|
| He might have been the unibomber in training.
|
| Don't want to pile on, but dude clearly seems to be going
| through mental issues.
| jayski wrote:
| or the insurance company jingle
| mrtksn wrote:
| The author apparently got political, had issues with the law
| enforcement: https://news.ycombinator.com/item?id=29839786
| alessioalex wrote:
| He's a nutjob that blew up his own house while trying to make a
| bomb or something. There's even an article somewhere. It's not
| the first time he's being ..weird.
| lightlyused wrote:
| I posted this earlier, but it got flagged.
| https://news.ycombinator.com/item?id=29859476
| lightlyused wrote:
| His twitter post.
| https://twitter.com/marak/status/1320465599319990272
| joshuaissac wrote:
| GitHub has now suspended the maintainer:
|
| https://nitter.net/marak/status/1479200803948830724
| DangerousPie wrote:
| > #AaronSwartz
|
| right...
| throw_m239339 wrote:
| Github and NPM belong to the same company, Microsoft.
| lloydatkinson wrote:
| Thank god.
| superkuh wrote:
| I don't understand why. It's his code to break if he wants. But
| I guess when you use a social media service to host your code
| these are expected and normal results.
| tester756 wrote:
| is this good or bad to be honest?
| ruuda wrote:
| This is why you pin all dependencies and upgrade (and test) when
| it's convenient for _you_, not when the author pushes a new
| version.
| laurowyn wrote:
| Pin all you want, if the repo/vendor/maintainer pulls the
| release then you're not getting access to your dependencies at
| all.
|
| If anything, this is the reason you use pull-through proxies.
| Your proxy will hold the version you depend on, regardless of
| upstream drama. Keep your proxy backed up and you'll be able to
| use those dependencies until the end of time, or you finally
| decide to migrate to an alternative.
| maxwell86 wrote:
| > if the repo/vendor/maintainer pulls the release
|
| If your package system allows this switch to another one,
| like, right now.
|
| NPM, Cargo, etc. don't allow this (they "unlist" versions,
| but they don't "remove" them, i.e. you can't search for them,
| but they are still there).
| cerved wrote:
| there are other benefits with proxies but fair point
| rane wrote:
| Offline cache with Yarn 2+ protects against this and other
| network failures when building CI, for example.
| commandlinefan wrote:
| > pin all dependencies
|
| You do that. Your coworkers don't. And they'll complain to your
| boss if you try to make them.
| toomanydoubts wrote:
| That's when you make a case for why you're pinning them,
| allowing your coworkers to present counterarguments.
|
| If your boss doesn't take your side, at least you can say "I
| told you" when things go wrong.
| bayesian_horse wrote:
| The only way to prevent this is to pin the actual commit.
| Because the meaning of the semantic version numbers is up to
| the package maintainers in most packaging systems. And even
| then you need a way to source exactly that version without
| relying on the original author's cooperation.
|
| Pinning all dependencies to this extent is extremely
| inconvenient. More inconvenient, arguably, than to deal with
| this shit once in a while...
| ownagefool wrote:
| That's what .lock files do though.
| shaunpersad wrote:
| AITA for thinking that if you develop open-source software and
| your license permits anyone to use it for free, then complaining
| about no compensation is not a valid complaint?
|
| I totally understand that billionaire corporations use software
| like this for free. But the software maintainer has explicitly
| allowed _anyone_ to use it for free. If you don't want them to
| use it for free, license it as such.
|
| What am I not seeing here?
| melony wrote:
| That's fine, but then the downstream shouldn't complain either
| when the code breaks, whether intentionally or unintentionally.
| The contract on paper disclaims all liability after all. There
| is a social contract and then there is the literal contract. A
| lot of commenters here seem to be willfully obtuse or simply
| ignoring the former.
| noobermin wrote:
| Amazing that the js community apparently learned nothing from the
| leftpad incident
| T3RMINATED wrote:
| ycIsGarbage wrote:
| notRobot wrote:
| Here's my $.02:
|
| Packages are literally remote code exec vulns in the hands of
| package authors. At the very least, it takes them under a minute
| to break your app, simply by deleting their package. Read the
| article. This is not the first time it's happened, and it's not
| going to be the last. [0]
|
| I write backends (mostly in PHP, although not exclusively), and I
| release a lot of my code under libre licenses. But I don't do
| packages. I don't want that level of control over other people's
| projects, it's scary as fuck. I have enough responsibilities as
| is.
|
| I have a mailing list for people who use my code, when an update
| is out they can download the .php files, 'require' them and test
| them before deployment, but never will I do packages.
|
| IMO, re-inventing the wheel sometimes is not the worst thing.
| Including code written by strangers that you haven't inspected
| and that they can remotely modify is. Stop using packages that
| are essentially wrappers around three-line Stack Overflow
| answers.
|
| In this case, the old-fashioned way is the better way, and you'll
| have a hard time convincing me otherwise.
|
| [0]: https://qz.com/646467/how-one-programmer-broke-the-
| internet-...
| MaxBarraclough wrote:
| > I don't want that level of control over other people's
| projects, it's scary
|
| How far do you take this though? The average GNU Linux distro
| ships with a whole pile of packages already installed, from a
| multitude of different authors.
| rajin444 wrote:
| There's no reason people can't keep local caches of these
| libs if it is a major concern. This seems like a non issue.
| MaxBarraclough wrote:
| Stale libraries are more likely to contain known security
| vulnerabilities.
| temp12192021 wrote:
| I know it's bad practice, but I just checkin vendor
| files/libs to source control. Makes auditing new releases
| of libraries a bit easier. Assuming they aren't binaries
| of course.
| cerved wrote:
| I don't recommend this approach
| temp12192021 wrote:
| I haven't had issues yet, but it's considered bad
| practice for a reason. What headaches am I in store for?
| jay_kyburz wrote:
| I also like doing this, but with node, you have a massive
| tree of thousands of files. It's crazy and gross.
| notRobot wrote:
| Yes, but AFAIK, those are heavily tested or audited in some
| manner. That's different from including code written by
| randos in your app that they can remotely change at any time.
| rich_sasha wrote:
| In practical terms, can they really be audited?
|
| This is at least obvious DoS, I'm sure it's easy to slip in
| an innocuous line that, dunno, ships your ssh keys to some
| rando server.
| cerved wrote:
| look at diffs?
| apetresc wrote:
| Can you really say, with a straight face, that you
| inspect the diffs of your entire dependency closure every
| time you deploy an update? With the level of scrutiny
| required to detect a maliciously-obfuscated security
| exploit?
|
| If you can, you're an infinitely more diligent developer
| than I am, that's for sure.
| tablespoon wrote:
| > Yes, but AFAIK, those are heavily tested or audited in
| some manner. That's different from including code written
| by randos in your app that they can remotely change at any
| time.
|
| It seems like the problem here is more cultural than
| technical, specifically that the JavaScript community has
| _fully embraced_ packages that are "written by randos"
| that are "wrappers around three-line Stack Overflow
| answers."
|
| I use packages, but I wouldn't use any that are developed
| by a rando with no reputation or "institutional oversight."
| An important part of choosing to use one is evaluating the
| maintainers.
|
| Does the JavaScript ecosystem have anything like Apache
| Commons? I'm guessing not, but it probably should.
| oblio wrote:
| It's both technical and cultural.
|
| Javascript is used on the front end. Front end devs
| obsess (or at least used to obsess) over download sized.
| So you'd have crazy stuff like custom builds of
| Underscore (https://underscorejs.org/) with just the
| functions you wanted. Think manual sandboxing, if that
| makes any sense. You could get a package of Underscore
| with just map, filter and reduceRight, if you wanted to.
|
| Now, when Node came around, people wanted as much as
| possible to have the same libraries available on the
| front end, so the same obsession with size was carried
| over.
|
| Ergo the micro-milli-nano-packages they make.
|
| Now, about the technical solution to this. We have this,
| for well defined programming languages (read: statically
| typed ones, or dynamically typed ones with a clear
| structure).
|
| It's a linker. Tech from the 1950s.
|
| Link (include) just the stuff you want, "tree
| shake"/"remote dead code" whatever you don't.
|
| https://www.joelonsoftware.com/2004/01/28/please-sir-may-
| i-h...
|
| Java's largely to blame for this, Sun REALLY, REALLY
| hated stuff that could be hooked into any OS and wasn't
| portable, so they didn't provide a linker. Everything was
| supposed to be on their JVM and you were going to install
| their JVM everywhere (2 billion devices!!!) and to hell
| with small stuff or heaven forbid, including native
| libraries. Javascript followed (on top of the Java
| restrictions they added: dynamic, poorly defined
| language, that would have made linking with tree shaking
| really hard, anyway). .Net also followed.
|
| Almost 3 decades later we're trying to undo that damage.
| jakub_g wrote:
| The problem with tree shaking has been twofold:
|
| - JavaScript is a very dynamic language with dynamic
| property access and a few other features that make it
| hard to guarantee that the linker won't accidentally
| remove too much
|
| - historically there was no standardized "module" format
| until ESM (ES modules) came up (with some time in between
| with few competing non-standardized proposals), so
| statically analyzing exports/imports was difficult; in
| frontend you'd long rely on just creating and reading
| global variables (i.e. side-effects).
|
| Hence it's been "safer"/easier to create small packages.
|
| But it's not only this. Once you put a mega-package in
| your repo, it's easy to gradually start relying more and
| more on the things it gives you. Even if it supported
| perfect tree shaking, you'd call one method here, one
| method there, and with each build your bundle size would
| balloon (which is not good if you could write one line of
| code while lib method's code is 1000 lines because it
| supports IE4 and 17 parameters).
|
| Whereas when you rely on small packages, you need to make
| a conscious choice each time to pick another dependency.
|
| You probably don't care about this on servers written in
| C++ or Java that much; but on frontend it's a big deal;
| hell, even when building native apps for Android/iOS you
| have size limits for the stores submission / limits for
| the number of methods (tech limitation in Android). Big
| companies invest crazy money to shrink their native
| bundle sizes (https://blog.pragmaticengineer.com/uber-
| app-rewrite-yolo/).
| oblio wrote:
| I think history (20+ years from now) will prove that for
| all but the smallest, almost toy, systems, dynamic typing
| from the 80s and 90s was a mistake.
|
| The maintenance burdens these languages are creating will
| make Cobol look like a kiddie bike with training wheels
| next to monster trucks.
| throw_m239339 wrote:
| > Does the JavaScript ecosystem have anything like Apache
| Commons? I'm guessing not, but it probably should.
|
| This isn't a Javascript problem, this is a node problem.
| Node is just a Javascript platform among many. The fact
| that the node community decided to go with all these
| "nano packages" has absolutely nothing to do with
| Javascript. Nothing forced Node, the distribution, to
| come with such a barebone standard library. Absolutely
| nothing... but the idea of being dependent of NPM which
| was orchestrated by NPM founders, that's how NPM, a
| private business made money and eventually sold to
| Microsoft.
| KennyBlanken wrote:
| Not just that they've fully embraced the "written by
| randos" but even worse: "as soon as the rando publishes
| an update or change, use it!" They seem to fully automate
| updates because packages are so poorly written (and
| frankly, it probably helps with revenue stream, if their
| client's websites occasionally break and need them to fix
| it.)
|
| ...and meanwhile NPM's idea of vetting packages is
| basically "YOLO, BRO!"
| bee_rider wrote:
| Packing is most of the point of a distro. They are
| specifically taking on that responsibility. They also have a
| better perspective to handle overall compatibility.
|
| In a sense you've pointed out the alternative to having the
| programmer handling the packaging -- having some third party
| package and distribute. And this separation of responsibility
| turns out be almost always be a better solution. Distribution
| and coding are, after all, two full jobs (without 100% skill
| overlap). Plus, hopefully it indicates that at least two sets
| of eyeballs have at least glanced at the code (not the full
| desired many-eyeball outcome, but as good as we can expect
| sometimes).
| drawkbox wrote:
| Dependencies are a major attack vector now.
|
| Tread carefully with all the supply chain attacks out there, it
| might not even be the authors doing these. We are entering a
| dependency attack massive war.
|
| Dependencies are a balance but also a sign of weakness of a
| system in the modern day. There at least needs to be delayed,
| dependency bot like analysis before you integrate. Even then,
| they just leave your systems open to worse than DLL hell,
| telemetry tracking/data, and attack vectors that can take down
| or target many, many systems.
| xg15 wrote:
| How about using dependencies but pinning the version and only
| updating if you know what the update contains?
|
| I'm still continually baffled that we ended up in a world
| where automatically accepting updates from every dev and
| their dog is not just the norm but recommended practice.
| heluser wrote:
| To resolve such issues the central maven repo, for example,
| makes artifacts immutable when you publish them
| infogulch wrote:
| Immutability feels like the best approach here. Go's module
| system is pretty good in this respect: "proxy" is just a
| proxy that serves module code, and "sum" is an append-only
| transparency log of the hashes of all published versions. You
| can't "unpublish" from the log, but you can get code hosted
| on proxy removed for various reasons... which users can
| protect themselves against by running their own proxy. Go's
| module version resolution strategy means that the chosen
| module version never changes without explicit input from the
| user so no "publish a new version that breaks everyone's CI"
| issue.
|
| All together I don't see how GP's "email php files around" is
| as any better than this system in any way.
| xienze wrote:
| A key difference with Maven projects is that you specify
| exact dependency versions instead of "always use latest" or
| some variant of that, as is pretty common in the Node world.
| julianlam wrote:
| npm does as well, they made this change after left-pad.
|
| You also can't unpublish once a single person has downloaded
| the package, I believe.
| mjlawson wrote:
| This is true for npm. After the incident with leftpad, you
| can't unpublish anymore. You can, however, publish a new
| patch update that completely breaks everything.
| throw_m239339 wrote:
| > This is true for npm. After the incident with leftpad,
| you can't unpublish anymore. You can, however, publish a
| new patch update that completely breaks everything.
|
| You absolutely can unpublish, it just requires more steps.
| If NPM gets a DMCA takedown request they will absolutely
| have to fulfill it.
| dathinab wrote:
| Except if they have reason to believe the code was
| uploaded with the permission of the copyright holder.
|
| The they have gotten the right for npm to distribute the
| source code in context of npm.
| throw_m239339 wrote:
| > The they have gotten the right for npm to distribute
| the source code in context of npm.
|
| There is absolutely no copyright or publishing right
| transfer that takes place when one "publishes" a package
| on NPM (or on Github). None.
|
| The original author is absolutely entitled to a DMCA
| takedown notice and NPM would have to oblige him.
| mschuster91 wrote:
| You can't legally retract opening up software source code
| under most if not all popular open source licenses.
| mjlawson wrote:
| Not only does it require more steps, it also has to meet
| the following criteria[1]:
|
| * no other packages in the npm Public Registry depend on
|
| * had less than 300 downloads over the last week
|
| * has a single owner/maintainer
|
| So while your point is taken that unpublishing is
| possible under some circumstances, it is not for popular
| packages that are in use today.
|
| [1] https://docs.npmjs.com/policies/unpublish
| throw_m239339 wrote:
| None of these points have any legal standing, from a
| copyright perspective.
|
| https://news.ycombinator.com/item?id=29868199
| dane-pgp wrote:
| > If NPM gets a DMCA takedown request they will
| absolutely have to fulfill it.
|
| Assuming the package is released under a Free Software
| licence, what grounds would there be for a DMCA takedown?
|
| I suppose a developer could include the lyrics to a pop
| song in their code (possibly encrypted), and then tell
| the copyright holder about it (since I don't think you
| can make a DMCA request on behalf of a copyright holder
| without their permission), but I would hope that such a
| poison-pill would be caught long before the package
| became widely depended on.
|
| Perhaps you're thinking someone would risk perjury(?)
| charges for making a false DMCA request against their
| package, and NPM would act on the request without
| questioning it; but remember that NPM is owned by
| Microsoft and they have previously stood up to frivolous
| DMCA requests (after a fashion)[0]. That article has the
| lede: "Software warehouse also pledges to review claims
| better, $1m defense fund for open-source coders".
|
| [0] https://www.theregister.com/2020/11/16/github_restore
| s_youtu...
| jonas21 wrote:
| Someone could have added non-free third-party code into
| the package (intentionally or inadvertently, it doesn't
| really matter).
| wbl wrote:
| Why does a new version break projects without action by the
| project owners? In Go you would have to explicitly update
| to the broken version.
| bspammer wrote:
| Because npm install has the insane default behavior of
| adding a fuzzy qualifier to your package.json, for
| example ^6.0.2 means all of the following versions are
| accepted: 6.0.2, 6.0.9, 6.7.84
| david_allison wrote:
| The defaults for npm and yarn install don't use the
| lockfile, and packages are installed by default via ^,
| which only locks the major version number.
|
| Commands: install and update => npm
| install: install from lockfile => npm ci
| install and update => yarn install install
| from lockfile => yarn install --frozen-lockfile
| inlined wrote:
| Because of version locks. Normally you install "^X.Y.Z"
| which means any version at major X with at least minor Y
| and revision Z. For more conservative codebases you
| install "~X.Y.Z" which also locks the minor.
|
| npm install will traditionally install the most recent
| packages that match your constraints. You need "npm ci"
| to use true version locks
| maxwell86 wrote:
| THat's why you specify the exact version of your
| dependencies.
| oblio wrote:
| Yeah, dude, but Java, yuck! Maven, yuck!
|
| Bros don't let bros touch (or read) Java.
|
| Who needs solutions implemented 15+ years ago?
|
| There are SO MANY things npm got wrong that's it's
| unfathomable.
|
| Another example of the many attacks they suffered was because
| they didn't implement (initially, I think) and then default
| to using groupIds. So everyone just squats the top level.
| Maven 1 didn't have groupIds either, then they found that was
| a problem, I think back in 2004. So Maven 2, in 2005,
| implemented groupIds. So it became almost impossible to have
| "no-name" libraries, think "httplib" or such. Everything is
| namespaced, think "com.foocorp"/"httplib".
|
| Edit: I wonder if the downvotes are because of the amount of
| sarcasm or people getting whooshed after the first paragraph
| and stopping reading :-))
| detaro wrote:
| npm also has immutable artifacts.
| oblio wrote:
| Yes, and my question is: why didn't they have them from
| day 1???
|
| Or at least day 1000? Npm was launched in 2010, 11 years
| ago, and I'm quite sure immutable packages were
| implemented about 3 years ago.
|
| Again, this is not rocket science, we knew the attack
| angles.
| detaro wrote:
| How does that solve the issue here of new broken versions of
| packages being published?
| oblio wrote:
| That's another JS ecosystem widespread malpractice.
|
| Autobumping versions, or version ranges as they're called
| in Maven land.
|
| Dependencies should only use fixed versions and all updates
| should be manual.
|
| You should only use auto-upgradable versions during
| development, and the package manager should warn you that
| you're using them (or your dependencies are).
| codebje wrote:
| If package A depends on package C at version 1.0 but
| package B depends on C at version 1.1, what version of C
| will be pulled in?
|
| Dependency management is not as simple as only upgrading
| one direct dependency at a time after careful review.
|
| The NPM ecosystem is particularly difficult to work with
| as it has deep and broad transitive dependency trees,
| many small packages, and a very high rate of change.
|
| You either freeze everything and hope you don't have an
| unpatched vulnerability somewhere or update everything
| and hope you don't introduce a vulnerability somewhere.
| ses1984 wrote:
| You shouldn't blindly pull updates into production, how do
| you know if a non-malicious update breaks your app if you
| don't do any basic testing first?
| msoad wrote:
| I do free work for open source _a lot_. I have a rather
| controversial opinion on this. I don't think I should be paid for
| my work because the moment money comes in I have to be
| responsible for the work I was doing for fun. I enjoy building
| cool things others can use for free and I want to reserve the
| right to respond to feature requests with a simple "PRs are
| welcome! :)".
|
| I get my paycheck from my employer and I have always been
| successful convincing my employers that I do open source work on
| the side for my own interest.
| phkahler wrote:
| What exactly does colors do?
| shepherdjerred wrote:
| https://www.npmjs.com/package/colors
|
| > get color and style in your node.js console
| Ostrogodsky wrote:
| It's incredible how far we have come
| guessmyname wrote:
| > _What exactly does colors do?_
|
| A picture is worth a thousand words -
| https://i.imgur.com/inxA7Pg.png
|
| The library inserts ANSI escape sequences [1] between the text
| you want to colorize in order to, well, colorize it
| -\\_(tsu)_/-
|
| Many people are obsessed with colors in the Terminal, and so,
| they reach out to libraries like this. They exist in every
| major programming language ecosystem, even though colorizing
| text is as simple as writing this \x1b[48;5;011<TEXT>\x1[0m .
| One of the disadvantages of this rudimentary colorization
| technique is that if you have short-term memory, you will
| quickly forget the meaning of these numbers, but you can solve
| that problem with constants, there is no reason to install a
| third-party library with potentially malicious code to add this
| type of functionality to a high-profile project like AWS-CDK
| [2].
|
| I wish these libraries would support NO_COLOR [3] more
| consistently.
|
| I have seen many "modern" CLI tools (the ones people like to
| build using Rust or Go) overuse colors with no option to
| disable them.
|
| [1] https://stackoverflow.com/a/33206814
|
| [2] https://github.com/aws/aws-cdk/pull/18324/files
|
| [3] https://no-color.org
| hnthrowaway0315 wrote:
| Why wouldn't everyone roll their own solution? Doesn't seem
| to be a huge thing to me, but I could be wrong...
| guessmyname wrote:
| > _Why wouldn 't everyone roll their own solution? Doesn't
| seem to be a huge thing to me, but I could be wrong..._
|
| Laziness; and people's infatuation for dependency trees,
| especially those in the Node.js & JavaScript ecosystems.
| [deleted]
| [deleted]
| evolve2k wrote:
| My sense is that it's time to evolve licensing such that wealthy
| major consumers of packages that have become somewhat essential
| are naturally paying a licence fee.
|
| The problem is not in what the code does it's a problem with the
| agreement for use.
| evolve2k wrote:
| Actually in attempting to answer my own question, on other
| platforms like YouTube and Medium, popular content receives
| monetary support by virtue of being popular.
|
| What if this was addressed at the "platform" level, I'm
| thinking the package manager here, NPM.
|
| If npm had paid plans that would essentially mop up larger
| corporations they could then auto-distribute funds Spotify
| style based on "number of listens".
|
| I'd personally want to see this work mainly as enterprise
| plans.
| tailspin2019 wrote:
| > If npm had paid plans that would essentially mop up larger
| corporations they could then auto-distribute funds Spotify
| style based on "number of listens".
|
| This seems like a pretty decent idea...
| rackjack wrote:
| This is already kind of happening with GPL for open source and
| Paid for commercial projects.
| sneak wrote:
| When you publish free software you give it away as a gift.
| That's the point.
|
| Expecting compensation for a gift is the error.
| throw_m239339 wrote:
| > My sense is that it's time to evolve licensing such that
| wealthy major consumers of packages that have become somewhat
| essential are naturally paying a licence fee.
|
| Yes, it's called paid software, but don't worry, it's going to
| be trendy again soon.
|
| The days of free software contribution are almost over.
|
| Devs want to be paid for their work. too many corporations made
| billions from open source projects while maintainers live in
| quasi poverty.
|
| What is needed is a proper market place for paid open source
| software. Github isn't one.
| laurent92 wrote:
| > proper marketing
|
| CVE are the proper marketing. The perspective of having a
| package with a vulnerability and no-one to provide a fix is
| frightening to any software maintainer.
|
| I think I could be extorted dozens of thousands for a single
| upgrade. Heck, when the electrician auditor says our office
| is not certified for 2022, I pay $700 for a professional to
| fix it. Software will be the same very soon.
| mrtksn wrote:
| For a bit more context:
| https://news.ycombinator.com/item?id=29839786
|
| In essence, It seems to be the case of a developer getting
| screwed, being disillusioned, becoming political, making bombs?,
| attacking the ecosystem etc.
|
| Many years ago, I recall another developer of popular NPM
| packages(Azer Koculu) pulling a similar thing[0].
|
| https://qz.com/646467/how-one-programmer-broke-the-internet-...
|
| We followed each other on Twitter, I recall him being
| disillusioned with SV and angry to Wikipedia for some reason(I
| think he believed on some greater plan or agenda pushed by SV
| companies, including Wikipedia). I disagreed and got unfollowed
| and blocked. Later, if I recall correctly. he got married and was
| touring the world.
| hnthrowaway0315 wrote:
| Programmers have all the power to hurt things but they rarely
| think about using that power. Sometimes it's not how much value
| you can create that wins the day, but how much pain you can
| strike at other people that counts. Politics is like that.
| Ugly, but necessary.
___________________________________________________________________
(page generated 2022-01-09 23:00 UTC)