[HN Gopher] What NPM should do to stop a new colors attack
___________________________________________________________________
What NPM should do to stop a new colors attack
Author : mfrw
Score : 118 points
Date : 2022-01-10 16:57 UTC (6 hours ago)
(HTM) web link (research.swtch.com)
(TXT) w3m dump (research.swtch.com)
| GeekyBear wrote:
| In this case, Microsoft seized ownership of an open source
| project and modified the code without the permission of the
| person who still controls those copyright rights that they
| haven't specifically waived.
|
| Legally, shouldn't Microsoft limit themselves to banning the
| developer from npm and forking their repos under a new name?
| profmonocle wrote:
| Microsoft isn't asserting any sort of ownership - colors.js is
| licensed under MIT. Microsoft is free to make whatever changes
| they like and redistribute said changes. (But as was already
| mentioned, they merely dropped the broken versions and set the
| last working version as "latest".)
| that_guy_iain wrote:
| Didn't they just revert it to a previous version? A version
| they are legally allowed to distribute? They are legally
| allowed to ban people and use whatever urls they want to host
| git repos. They are also legally allowed to give someone else
| permision to npm publishing under a specific package name.
|
| Seems like they did things they are allowed to do.
| iakov wrote:
| I believe you are right. This behavior of m$ is really nasty,
| but should not surprise anybody. Look at what happened to Net
| Foundation.
| howdydoo wrote:
| Summary:
|
| The author argues that version bounds should be treated as a
| maximum rather than a minimum, like Go does. e.g., if the latest
| version of colors is 1.0.3, and you have dependencies that
| request 1.0.1 and 1.0.2, you would end up with 1.0.2. The end
| result being, the exact resolved version will have been tested
| with at least one of your dependencies.
|
| I must admit I like the idea.
| Hizonner wrote:
| Except that a shit-ton of developers will code and test with
| one version of a dependency, and never, ever, ever update it.
| If the dependency has a catastrophic security hole, that
| security hole will be pretty much permanent.
|
| And what happens if project A pins projects B and C, which in
| turn pin DIFFERENT versions of project D? Is there any language
| or environment out there that can make that work?
| howdydoo wrote:
| Read it again. Any one dependency, or the root project, has
| the power to pull in the latest version. One laggard
| dependency does not stop that.
|
| For your second question, yes, Rust handles that well. If you
| depend on ">=1.0" and ">=1.1", you end up with a single copy
| of 1.1. If you depend on "=1.0" and "=1.1", you end up with
| _both_ copies of the library. Every crate uses the version it
| requested. You can argue whether that 's good or bad, but at
| least it's principled. There's a lint if you dislike that
| behavior.
|
| https://rust-lang.github.io/rust-
| clippy/master/#multiple_cra...
| littlestymaar wrote:
| > For your second question, yes, Rust handles that well. If
| you depend on ">=1.0" and ">=1.1", you end up with a single
| copy of 1.1. If you depend on "=1.0" and "=1.1", you end up
| with both copies of the library. Every crate uses the
| version it requested.
|
| IIRC rust only does that for MAJOR versions (1.1 and 2.0,
| or 0.2 and 0.3, since cargo consider releases before 1.0.0
| to be major ones).
| Hizonner wrote:
| OK, so suppose I depend on anarchy, which wants shades
| >=1.0.1, and chaos, which wants shades >=1.0.2. The author
| of shades releases 1.0.3 because of a bad security hole in
| all prior versions. My project will still get 1.0.2, so it
| will still have the security hole. For that matter, it may
| ALSO break because anarchy is broken by a change made
| between shades 1.0.1 and 1.0.2... which is why the
| maintainer of anarchy hasn't updated their dependency.
|
| On the whole, I think I'd prefer a solver that gave me
| 1.0.3 by default (but maybe would NOT give me 2.0.0 by
| default, depending on what the version numbers mean in this
| particular system). But the bottom line is that there is NO
| solver that can be SURE that what I eventually get will
| really work.
|
| That's an interesting fact about Rust, and I didn't know
| it. On the whole, it sounds like it at least needs some
| serious tooling so you can make sure you're not dragging in
| a bunch of old versions that both bloat your code and open
| you to abuse. Can I ask for a warning if I'm getting two
| different versions linked into the same binary? If
| something depends on "=1.0", and the maintainer issues 1.1
| with a flag that says "I really, really don't think think
| you should be using 1.0 any more", will that throw an
| error? And what happens if both versions get pulled in, but
| the package in question uses an external data file whose
| format changed between 1.0 and 1.1?
|
| Edited to change "<=" to ">="...
| Hizonner wrote:
| Oh, and another Rust question, if you don't mind. If I
| have both versions 1.0 and 1.1 of package X in my binary,
| and X defines a data type called foo, and one of my
| dependencies constructs a foo using X 1.0, is that value
| of a different type than a foo constructed by X 1.1? Or
| can version 1.0 foos wind their way through the code and
| up being processed by version 1.1 code?
| howdydoo wrote:
| > My project will still get 1.0.2, so it will still have
| the security hole.
|
| Right. To mitigate that you would regularly run `npm
| audit` or even just `npm upgrade` - and test afterwards
| of course.
|
| I'm not completely sold, but I do think it's a very
| interesting idea.
|
| > Can I ask for a warning if I'm getting two different
| versions linked into the same binary?
|
| Yes. That was the lint I linked in my last post.
| Alternatively, you can run `cargo tree --duplicates`.
|
| > "I really, really don't think think you should be using
| 1.0 any more"
|
| That's called "yanking". Personally I think it has
| limited usefulness, but it exists.
|
| https://doc.rust-lang.org/cargo/commands/cargo-yank.html
|
| > And what happens if both versions get pulled in, but
| the package in question uses an external data file whose
| format changed between 1.0 and 1.1?
|
| If it uses something like `include!`, both copies will be
| compiled in (and maybe optimized later by the linker). If
| it's truly "external" like hosted on some website outside
| the package manager, then it just means the author broke
| their package. Maybe I misunderstood your question.
|
| > one of my dependencies constructs a foo using X 1.0, is
| that value of a different type than a foo constructed by
| X 1.1?
|
| I believe they are always different types. Cargo
| encourages but doesn't enforce semver, so anything can
| change between versions, including private fields or enum
| variants behind non_exhaustive, etc. So they're treated
| as different and you need to convert between them.
| Although this might only be true for major versions; I
| don't know off the top of my head.
|
| To work around it you can convert the types at crate
| boundaries, or the package author can use the so-called
| "semver trick" [1]
|
| [1]: https://github.com/dtolnay/semver-trick
| rwj wrote:
| I agree that this approach is much better for stability. The
| trade off is that a lot of systems will end up missing their
| needed security updates. Very few people are consciously
| balancing their type I and type II errors when considering
| upgrade strategies.
| shagie wrote:
| This in part has to do with how versions are specified and the
| standard way that this is done allows minor and point releases
| to be trusted.
|
| https://stackoverflow.com/a/22345808 - and especially the
| comment.
|
| You will find a lot of `^1.2.3` in version specifications which
| means everything from `1.2.3` up to (but not including) `2.0.0`
| is allowed.
|
| Specifying `1.0.1 - 1.0.3` is allowed too and would meet the
| desired functionality - but that isn't the culture of
| JavaScript developers.
|
| The version range is allowed in other dependency management
| systems (e.g. Maven - https://www.mojohaus.org/versions-maven-
| plugin/examples/reso... ) but rarely do I see it used - most
| often its pinned to a specific known good version.
| howdydoo wrote:
| Let's say you have two dependencies each requesting colors:
|
| colors@1.0.1-1.0.3
|
| colors@1.0.1-1.0.4
|
| With npm, you'll end up with 1.0.3 because it satisfies _all_
| constraints. OP wants to end up with 1.0.4 if _at least one_
| dependency tested with 1.0.4 (and reject 1.0.5). I don 't
| know of a way to do this with npm today.
| gitgud wrote:
| You might like the [1] "overrides" field in npm v8.3
| although I would recommend using it with caution, changing
| your dependencies dependencies has unknown consequences...
| even a patch release can break everything...
|
| [1] https://docs.npmjs.com/cli/v8/configuring-npm/package-
| json#o...
| gknoy wrote:
| > the standard way that this is done allows minor and point
| releases to be trusted.
|
| I feel like this event (and previous ones) has taught me that
| one should NOT trust patch and minor version upgrades to
| work. Obviously we want them to, but I distinctly recall
| having "minor" patches that broke existing behavior in the
| past, and has bitten my team on multiple projects over the
| last several years. Pinned versions are a giant pain, but
| having builds suddenly stop working seems worse, because you
| can't plan ahead for the time to upgrade.
| shagie wrote:
| I've come to believe that pinned versions with an active
| dependency check is the way to go. A lot of the dependency
| checks/scans are build time rather than an "on going"
| approach.
|
| If nothing else, that is a step in the direction of
| reproducible builds which are also in the Good Thing
| category.
|
| This is likely going to be another maturing event for NPM
| and the community where they will need to decide how they
| want to move forward. The blind trust of a `^1.2.3` version
| specification is something that will likely be outgrown.
|
| I still believe that one of the biggest problems that
| JavaScript libraries face is the transitive dependency
| explosion combined with the "always update" build policies
| and that in turn makes makes the issue of a suddenly
| untrustworthy developer more likely and more problematic.
| aardvark179 wrote:
| How about a foundation to run the package repository (for
| independence), a requirement for multiple sign offs to publish an
| artefact, and a requirement that successor maintainers exist?
|
| Yes, this would create a barrier to entry, but I'm not sure
| that's a bad thing.
| pictur wrote:
| What exactly is this person's motivation to do this? Interest?
| What does he want to draw attention to?
| diogenesjunior wrote:
| when i have any code that requires dependencies, i always use an
| exact version. i am mainly a python developer, so my
| requirements.txt would look like this:
| flask==1.1.1 request=2.3.2 tensorflow==3.4.2
|
| i tested/built my code with these versions, so i know that these
| versions work. when i install my dependencies, i use these
| versions, not the latest version. is there a way to do this with
| node.js? and wouldn't using this method solve any problems?
| pardon me if i'm missing something
| rronalddas wrote:
| Yeah, it can be done easily using lockfiles, both yarn and npm
| allow that. You would seldom run npm update directly in
| production without testing the updated deps first
| cjpearson wrote:
| Yes, if you put exact versions in your package.json and do not
| prefix them with a caret or tilde, npm will install the exact
| version. A package-lock.json version will also pin your
| transitive dependencies to a specific version. Unfortunately,
| the default behavior of npm is to add a caret to the version
| number which npm interprets as this version or any greater
| minor/patch release.
| tln wrote:
| Yes, you can specify an exact version in package.json. The
| easiest way is by adding "-E" when installing:
| npm install chalk -ES yarn add chalk -ES
|
| The -S installs and saves to package.json (equiv to
| requirements.txt).
|
| That results in: "dependencies": {
| "chalk": "5.0.0" }
|
| which is an exact dependency. By default npm and yarn use
| "^5.0.0" which means minor upgrades are allowed (5.x.x).
| franciscop wrote:
| The whole "grab the latest semver compatible version" was
| designed for a reason, and just pinning to a specific version
| would bring us to a world where very different articles need to
| be written. Specifically, when there's a vulnerability in any
| dependency (a thing that happens much more often than a rogue OSS
| dev) the upgrade process would be a nightmare for everyone
| involved.
|
| You have to chose one of the two evils; automatic
| bug/vulnerability fixes, or protection against rogue OSS devs you
| depend on. I'd say the former is an order of magnitude more
| important, and so the npm/JS world works this way.
| alana314 wrote:
| Maybe the JS language itself should vet and absorb some of these
| more common libraries. Printing pretty colors in a console could
| be a feature of the language itself.
| throw_m239339 wrote:
| > Maybe the JS language itself should vet and absorb some of
| these more common libraries. Printing pretty colors in a
| console could be a feature of the language itself.
|
| Maybe Node.js should start shipping with a substancial standard
| library instead of making developers rely on NPM. Node.js can't
| even parse a multi-part request body without a third party
| library. So much for a HTTP server that doesn't even implement
| the HTTP spec...
| soylentgraham wrote:
| What if my engine doesn't have a pretty console?
|
| Javascript isn't just node and web browser scripting.
|
| Things like UI should not be in the language.
| o_m wrote:
| Isn't Deno doing this with its own standard library?
| pawelmurias wrote:
| A standard library over time would end up consisting of ancient
| garbage. You could have a vetted collection of node.js module
| on npm.
| CottonMcKnight wrote:
| There is a TC39 proposal for a "Javascript Standard Library."
| It's at stage 1, which is better than stage 0.
|
| https://github.com/tc39/proposal-built-in-modules
|
| Even so, unlikely that a "Faker" would become part of any such
| standard library.
| andrewmcwatters wrote:
| Easy, make --save-exact default behavior. We don't have stable
| subresource integrity in Node.js yet, but this would be the next
| best thing.
| dang wrote:
| Recent and related:
|
| _Dev corrupts NPM libs 'colors' and 'faker', breaking thousands
| of apps_ - https://news.ycombinator.com/item?id=29863672 - Jan
| 2022 (955 comments)
|
| _Important NPM package colors from Marak causing console
| problems at the moment_ -
| https://news.ycombinator.com/item?id=29861560 - Jan 2022 (1
| comment)
|
| _Creator of faker.js pushed an update of colors.js which has an
| infinite loop_ - https://news.ycombinator.com/item?id=29855397 -
| Jan 2022 (1 comment)
|
| _Marak adds infinite loop test to popular colors.js_ -
| https://news.ycombinator.com/item?id=29851065 - Jan 2022 (7
| comments)
|
| _Marak 's GitHub account suspended after he erased his faker
| project_ - https://news.ycombinator.com/item?id=29837473 - Jan
| 2022 (53 comments)
|
| _Faker.js Erased by Author_ -
| https://news.ycombinator.com/item?id=29822551 - Jan 2022 (2
| comments)
|
| _Popular JavaScript package "Faker" replaced with message about
| Aaron Schwartz_ - https://news.ycombinator.com/item?id=29816532 -
| Jan 2022 (3 comments)
|
| _Faker.js Has Been Deleted_ -
| https://news.ycombinator.com/item?id=29806328 - Jan 2022 (9
| comments)
| [deleted]
| mavhc wrote:
| Is it possible to have users vote on whether a new version is
| "good"?
|
| Maybe automatically via software that depends on the module
| successfully completing test suites?
| shadowgovt wrote:
| It's worth asking, I think, how much energy should be spent
| against guarding against an attack like this in the future. I
| think every organization's risk model is different.
|
| In this case, the Net interpreted Marak's actions as damage and
| seems to have effectively routed around them. There was
| disruption, but we already have systems in place for flagging
| broken or malicious versions (`npm audit` being one example).
|
| For people willing to have the system work 99% of the time with
| the occasional Marak-screw, we already have a working solution in
| what currently exists. For people who cannot tolerate that level
| of risk, you have to firewall your package sources and only allow
| use of vetted code dependencies in your software.
|
| Open source relies, in the end, on trust. Marak broke trust and
| that's all. The question isn't "How do we prevent people breaking
| trust" (that's impossible; humans have free will) but instead
| "How do we mitigate damage / protect that which cannot be risked
| if someone chooses to break trust?"
| jeffrallen wrote:
| I cannot fathom why Russ bothered writing this. Npm is a dumpster
| fire, and below him.
| freeqaz wrote:
| I've used NPM shrinkwrap before back in versions 1-3 of NPM. It's
| a little confusing that the author of this post calls it "new",
| so I investigated.
|
| Since NPM version ~2 (current is 8), you're allowed to publish a
| npm-shrinkwrap.json file[0] in your package. That's in contrast
| to a package-lock.json, which may not be included in a published
| package.
|
| Back when I used shrinkwrap, it was pre-lockfiles and it was
| trying to accomplish something similar to what lockfiles
| accomplish today. (Lockfiles were added in v5 [1])
|
| I dug up this old StackOverflow post to verify that the behavior
| of shrinkwrap hasn't changed[2] since many years ago.
|
| That doesn't leave me very hopeful. If package maintainers aren't
| doing this already, and they've been able to for 6+ years, then
| it's unlikely they will in the near future.
|
| (I'm currently investigating how to deal with bad deps with some
| Open Source tooling I'm building. Feel free to ping me if you
| have any thoughts to share)
|
| 0: https://docs.npmjs.com/cli/v8/configuring-npm/npm-
| shrinkwrap...
|
| 1: https://nodejs.dev/learn/the-package-lock-json-file
|
| 2: https://stackoverflow.com/questions/44258235/what-is-the-
| dif...
| epmatsw wrote:
| It's because having an actual shrinkwrap file in a library
| introduces a huge number of conflicts. If library A has 20
| transitive dependencies, and library B has the same 20
| transitive dependencies, deduplication based on ranges can
| leave you with only 20 transitive dependencies. If both
| libraries have shrinkwrap files in them, you can end up with 40
| transitive dependencies, even if those are nominally compatible
| with each other. When you consider that even with the current
| behavior projects end up with thousands of transitives, you're
| looking at adding literally thousands or 10s of thousands of
| duplicate dependencies to a project. That's not even
| considering that some duplicate dependencies will just break
| things if they show up multiple times in a project (older
| versions of react, for example).
| freeqaz wrote:
| Ah, that totally makes sense. I know that's what
| "peerDependencies" is used for by many projects. For example,
| `react-dom` has a peerDependency on `react`. This can either
| be pinned to an exact version (react-dom@1.1.1 must be used
| with react@1.1.1) or it can require a range (react-dom@1.1.1
| may be used with react@^1.0.0 (any version 1.0.0 and up)).
|
| That seems tricky with the shrinkwrap, as you describe above,
| because it might create additional versions everywhere
| instead of trying to collapse them. (If you have 3 versions
| of `react` in peerDependencies, but each package had a npm-
| shrinkwrap.json, then you'd end up with 3 different versions
| of `react` installed.)
|
| Would the burden then fall on your package manager to resolve
| this, ie npm or yarn? If it sees 3 different shrinkwraps
| (1.1.1, 1.1.2, 1.1.3) but they all have compatible
| peerDependencies (>=1.1.1, >=1.1.2, >=1.1.3) it could then
| pick the version that is compatible with all of the
| peerDependencies but that also exists in a shrinkwrap (so
| 1.1.3).
|
| That would protect you from this "colors" scenario of
| somebody publishing `1.1.4` with malicious changes because,
| unless somebody were to shrinkwrap it, then it wouldn't get
| picked up by default. (In contrast to the current semver,
| which likely would pick up 1.1.4 upon a fresh `npm install`).
|
| The inverse side of this is highlighted by another comment on
| this post: That semver makes absorbing security updates an
| easier process in the event of a log4j-style vulnerability.
| There is always a tradeoff, for sure!
| er4hn wrote:
| It is worth noting that this is not an impossible problem.
| I'm not a js expert, and it seems that js loves imports, but
| Nix solves exactly this problem on Linux. You have, for each
| end binary, a set of dependencies. If they are exactly the
| same, they can be shared among programs, otherwise you would
| have different versions of the dependency, all the way down,
| per program.
|
| It can be bloaty, and you have to manually look at and test
| packages if you want to get everyone on the same set of
| dependencies, but you end up with reproducible environments.
| smasher164 wrote:
| > Essentially every open source software license points out that
| the code is made available with no warranty at all. Modern
| package managers need to be designed to expect and mitigate this
| risk.
|
| It's almost like the package manager's job has become to protect
| users from their dependencies.
| selfhoster11 wrote:
| Protecting users from their dependencies should be the job of
| their language's standard library. With a good enough stdlib,
| the number of dependencies required is much lower.
| smt88 wrote:
| It is very reasonable to ask NPM, owned by mega-giant tech firm
| Microsoft, to protect users from malicious packages.
| kardianos wrote:
| Package managers should not intentionally expose users to new
| versions without explicit action.
|
| Go modules did different then npm, and I argue Go modules did
| it correctly.
| pmoleri wrote:
| Until the opposite happens. Some big security hole is fixed
| in the dependency, npm gets the fixed version by default
| while Go is stuck in the tested unsecure version. Or Go
| mitigates the somehow?
| jrockway wrote:
| Go doesn't mitigate that somehow. You get the code that you
| specify, not the code that someone else has decided is
| better.
|
| In practice, for both npm and Go dependencies, you'll get a
| Dependabot PR that upgrades the dependency for you.
| Obviously that is Github-specific, so if you're on a
| different platform, you'll have to subscribe to security
| updates in some other way. I am guessing there are many
| services that you can subscribe to that do the same thing.
| bhedgeoser wrote:
| Some big security hole is introduced in one of thousands of
| dependencies, npm gets the insecure version on next npm
| install while Go is stuck in the tested secure version. How
| difficult is that to see? I'm not the one to believe in
| conspiracy theories but this is just nuts.
| smasher164 wrote:
| I agree that Go made the right call with MVS. It's a nice
| compromise between pinning and fetching the latest version of
| everything.
| no_wizard wrote:
| Attack is hyperbole. This wasn't an _attack_. Nothing was
| _attacked_. This verbiage has got to stop being used around this.
| A maintainer of popular packages got fed up with being a
| maintainer - rightly or wrongly - and decided that they were
| going to alter their code - publicy no less (a far more dubious
| move would have been to make these changes in private and release
| that to npm, without pushing it to github also, in my mind) - and
| that means this code was working as intended by the project /
| package maintainer.
|
| It was not injecting harmful code onto the machine, it was not an
| "attack" on anything, in any real sense. I feel all the media is
| doing so far is raking the maintainer over a fire, instead of
| asking the question of _how did we get here in the first place?
| Why would a maintainer feel they need to take actions like this?
| What are they trying to achieve?_
|
| Instead of talking about the role of maintainers, consumers, and
| what to do about the state of open source software and its
| longevity, we are instead using this moment to go after the
| maintainer as if they were doing the equivalent of using their
| npm packages to inject actual malicious, harmful code on the
| consumer machines, like a cryptominer.
|
| I know it inconveniences everyone, sure, and would I have done
| this if they were my packages? No, I'd go through a normal
| deprecation process of announcing its deprecation, archiving the
| repository, and plainly stating that the package is no longer
| maintained. With that said, _consumers can always choose a
| different library._
|
| This wasn't malicious, or an attack. It was an update to the
| package working as the maintainer of the project intended. If
| lodash issued a breaking change, would that be considered an
| "attack"? They even followed semver, by bumping the packages to
| their next major version.
|
| I think this event also served to expose how little organizations
| have around testing for breaking changes in their dependencies,
| which may be adding fuel to the issue.
| blitz_skull wrote:
| What he did was actively malicious. There was ill-will behind
| the actions. He did it for the purpose of interrupting a lot of
| stuff that was working, simply to make some sort of statement.
| It was an attack, by ALMOST any definition. The fact that it
| was a very benign attack with very few real consequences,
| doesn't make it less of what it was--an attack.
| keneda7 wrote:
| He did not force anyone to update the package. They did that
| without looking at it. He no longer wanted his work to be
| disturbed. You may not agree with how he did it but calling
| it an attack is completely ridiculous.
|
| These comments on HN are sending a pretty clear message
| out... don't open source anything. It is really really
| unfortunate.
| chaostheory wrote:
| No one expects a maintainer to purposely break their
| project. If he wanted to end it, he should have just sent a
| goodbye message signaling the end of his involvement with
| maintenance. This has been done many times before without
| incident. If he wanted to be paid, he should have either
| picked the appropriate license for his software from the
| start, or just changed it for future versions. The latter
| has also been done before with SugarCRM being one example
|
| To be fair, Marak seems to be mentally unwell right now,
| which helps explain but doesn't condone his behavior
|
| https://abc7ny.com/suspicious-package-queens-astoria-
| fire/64...
| kwinten wrote:
| This is so ass-backwards and you're practically twisting
| yourself over backwards a dozen times to somehow try to
| argue that this wasn't malicious. He basically poisoned the
| library, and you're blaming all the people who got poisoned
| because "they didn't fully inspect the contents of the
| code".
| [deleted]
| encoderer wrote:
| I think you're being far too kind in your interpretation. If
| one wishes to stop maintaining, all you must do is nothing.
| Instead, by pushing an intentionally broken patch, It is
| foreseeable that there will be hundreds or thousands of
| maintainers of other code that will have to respond to your
| actions. I think it's reasonable to call that an attack.
| toomuchtodo wrote:
| If you consume open source code without reviewing it, it's no
| different than executing arbitrary user code. Your
| environment's security is based on hope and trust.
|
| Maintainers shouldn't be malicious, absolutely, but users
| should do a bit more than pulling code and running it.
| Otherwise, it's curl | bash dressed up with a ci pipeline.
| How many times does dependabot bump your dependency revisions
| and no one looks except to ensure tests pass?
| encoderer wrote:
| A lot of it is based on trust, that's evidently true, and
| as such, I think it's perfectly fine to publicly shame a
| maintainer who looks to have breached that trust.
| bergheim wrote:
| Doing this for something like GNU/Linux is simply not
| practical, _at all_. In what world can a user be expected
| to do little else that simply install linux? Since you
| pipe, can I assume you know everything about the kernel
| tree?
|
| And bad actors work in companies as well. At some point you
| just have to trust what you are using.
| caymanjim wrote:
| People install Linux by picking a distribution to
| install. The maintainers of the distributions look at the
| packages they're including. For example, this broken
| colors package will never end up in any of them, because
| there are gatekeepers.
|
| It's certainly impractical for every developer to vet
| every package they use, so much so that almost no
| developers vet any of the packages they use. What's
| needed are more gatekeepers. Repos like NPM would be
| well-served by coming up with mechanisms to support this.
| Off the top of my head, some sort of "this is safe"
| consensus, whereby the community can vouch for specific
| immutable versions of packages, that don't become the
| default version until they cross a threshhold.
| Organizations with a history of good stewardship and
| trusted validation processes could be allowed to skip the
| vetting step (e.g. things published by groups like the
| Apache Foundation or even corporations like Microsoft).
| I'm not arguing that one-man shops shouldn't be able to
| publish to NPM, just that there should be something like
| a "--untrusted" flag that's required before unverified
| updates are installed. And I'm not calling out NPM; every
| package repo has this problem.
| toomuchtodo wrote:
| I agree we've built a metropolis on sand, and a large
| component of solving for this problem is going to be some
| form of trust and managing that trust (more code reviews
| with an audit trail of some sort, human gating of code
| changes using automated risk modeling, etc).
| fivea wrote:
| >>I think you're being far too kind in your interpretation.
| If one wishes to stop maintaining, all you must do is
| nothing.
|
| This sounds like a gross misrepresentation of what happened.
|
| It has been reported that the author of the colors and faker
| packages announced last year that he was no longer willing to
| do free work for Fortune500 companies.
|
| He also proceeded to state quite publicly that either
| companies paid him for his work, or they should fork the
| project and maintain it themselves instead of taking
| advantage of everyone else's work.
|
| After a year has passed, the author proceeded to release a
| couple of major versions that had a more artistic feel.
|
| https://web.archive.org/web/20210704022108/https://github.co.
| ..
|
| Source:
|
| https://www.theverge.com/2022/1/9/22874949/developer-
| corrupt...
|
| These packages are his circus, and his clowns run the act he
| chooses.
|
| If anything, this update showcases the completely abhorrent
| security culture in place in these mega-companies, which
| literally ingest into their product line anything that they
| can find on GitHub without a shred of due diligence.
| acdha wrote:
| > After a year has passed, the author proceeded to release
| a couple of major versions that had a more artistic feel.
|
| Artistic would be a new color scheme or maybe a "support
| open source maintainers" message. The accurate description
| you didn't give is sabotage because he introduced an
| infinite loop:
|
| https://github.com/Marak/colors.js/commit/074a0f8ed0c31c35d
| 1...
| jamincan wrote:
| In what world is it not malicious? He owned the packages and I
| guess that gives him the right to do what he likes with it, but
| I have a hard time believing he didn't do it deliberately fully
| aware that a whole bunch of people would update and it would
| cause disruption. It's not an exploit, but it's certainly
| malicious, and I don't think it's unreasonable to call it an
| attack.
| foobiekr wrote:
| People who were pulling this unvetted and live are lucky he
| did not sell it to a malware group.
| no_wizard wrote:
| Sure did, however, does that mean its malicious?
|
| The definition of malicious, according to Merriam Webster[0],
| is the following
|
| > _having or showing a desire to cause harm to someone :
| given to, marked by, or arising from malice_
|
| Was the intention here to cause someone harm? What the
| intention here _malice_? Which conversely has this
| definition[1]
|
| > _desire to cause pain, injury, or distress to another_
|
| Was this their _primary motivation_? What evidence do we have
| that is in fact an action driven by malice? In fact, I don 't
| see any, especially after doing roughly 20 minutes of
| research, I have arrived at the following:
|
| Reading the public history surrounding the maintainer of
| these projects, the issue trackers of the repositories, and
| the maintainers own blog, you may come from a different
| conclusion entirely. If I was to speculate - and mind you, I
| am speculating, as I don't know the maintainer personally nor
| do I claim to understand them completely - there is a clear
| sense of mental strain they are feeling from the burdens
| here. Being burnt out, feeling taken advantage of, can lead
| to very real and deep feels of _depression and /or other
| mental challenges_ (this I speak first hand to), for
| starters. I think the maintainer - again, speculating here,
| however evidence does seem to suggest this - is acting from a
| place of disillusionment, and possibly is _resentful_ of
| their status in the word, relative to those benefiting from
| their contributions to open source software. Are they right
| to feel this way? Maybe, maybe not. However, is this
| _malice_? That 's the question. Is this actually malicious?
| All evidence points to no, its not an act of malice. Its an
| act of someone who is disillusioned, strained, and
| struggling. I think the most reasonable interpretation given
| all the evidence is that they are trying to raise some kind
| of awareness - albeit in ways that I don't think is well
| communicated, due to the issues I previously highlighted -
| most likely.
|
| I could be wrong, I'm just following the publicly available
| evidence and, its a lot more murky than _this is an malicious
| act by a malicious maintainer acting in malice_.
|
| And again, this brings up the broader issue around open
| source maintainability, longevity, the role of consumer and
| maintainer, and how to build better symbiotic relationships
| around that, yet we aren't talking about what _lead to this
| event_ , which I would argue is more important than what
| happened.
|
| My ask is for nuance in this conversation, where there is
| seemingly little.
|
| [0]: https://www.merriam-webster.com/dictionary/malicious
|
| [1]: https://www.merriam-webster.com/dictionary/malice
| slibhb wrote:
| Pushing broken code on purpose is malicious.
| [deleted]
| Shaanie wrote:
| You write a lot of words to explain how the maintainer
| could justify his malice. At the end of the day it's still
| done out of malice, though.
|
| Unless he's gone absolutely bonkers, he's doing this to
| intentionally cause damage. The reason for it does not
| matter, as the definition you posted helpfully points out.
| no_wizard wrote:
| Is it though?
|
| Was it malice when maintainers started adding those
| posinstall scripts asking for funding? which lead
| directly to the creation of `npm fund`, for instance. Was
| that also malice?
|
| Given all the evidence we have - I think its murky.
| That's my point, at the end of the day.
|
| Arguably, I could say that making millions of dollars off
| an open source library and not contributing back is
| malice - yet that argument is rarely given the same open
| and shut approval.
|
| Mind you, this is bigger, IMO, than `faker.js`, this
| raises questions around _open source software as a whole_
| , that are relevant in this case and beyond
|
| There's nuance in this conversation that is missing so
| far.
| FunHearing3443 wrote:
| I keep seeing this comment that companies are making
| their millions 'off of open source libraries' and it's a
| catchy phrase but let's be real the big companies that
| are using faker JS are making an insignificant amount
| extra by using that library, there are alternatives to
| mock data, etc. A key feature of MIT style licenses is
| that you can do whatever the hell you want with it for
| free, use a more restrictive license if you don't want
| people making a bunch of money off your code. I feel bad
| for this maintainer but a good takeaway is probably to
| not do a bunch of work for free unless you see a path to
| income down the road from it.
| watwut wrote:
| It is actively anti open source argument. It makes
| limited sense in subculture where contributing to open
| source is expected, but that subculture is absurdly small
| and answer to it is "this absolutely should not be
| mandatory".
|
| In any other context, it is argument against open source
| existing.
| acdha wrote:
| > Was it malice when maintainers started adding those
| posinstall scripts asking for funding? which lead
| directly to the creation of `npm fund`, for instance. Was
| that also malice?
|
| No, because that did not impair use of those libraries
| whereas this change deliberately broke every program
| written by someone who trusted him and used his code
| under the social contract he offered.
|
| Open source maintainer funding and burnout are real
| problems but betrayal won't make things better. Imagine
| if you lived in a house with a bunch of roommates who
| weren't doing their share of the housework -- you're
| entirely within your rights to stop volunteering to clean
| the toilet but it's crossing a line if you instead modify
| it to flush up.
| acdha wrote:
| It broke a ton of other people's projects, on purpose. You
| can argue that he could have done much worse -- say
| exfiltrating all of the AWS credentials from CDK users -
| but there's no definition where it's not an abuse of trust
| to sabotage your users.
|
| https://github.com/aws/aws-cdk/issues/18322
| zdragnar wrote:
| Nobody had to upgrade. Anyone who accidentally upgraded
| because their dependencies had sloppy programming
| practices should be mad at their direct dependencies.
|
| aws-cli should not be an attack vector, and if it is, AWS
| engineers are at fault.
| chaostheory wrote:
| This is a terrible argument. Marak didn't have to
| purposely break anyone's projects either. If he wanted to
| end it, he should have just sent a goodbye message
| stating end of his involvement and walked away. This is
| the normal thing to do. If he wanted to be paid, he
| should have either picked the appropriate license at the
| beginning, or just changed it for future versions. The
| latter has also been done before with SugarCRM being one
| example. Something as free for all as the MIT license
| sends the wrong message.
|
| This has been posted before, but Marak seems to be
| mentally unwell right now, which helps explain but
| doesn't condone his behavior.
|
| https://abc7ny.com/suspicious-package-queens-astoria-
| fire/64...
| acdha wrote:
| I don't know what makes you want to try to gaslight
| people on marak's behalf but this is a pretty poor
| attempt at doing so. He published a deliberately broken
| update with a non-breaking version number change to a
| package management ecosystem where the community expects
| to follow a semver-ish model where point updates do not
| break things. This is an abuse of trust, just like it
| would be if you said "I'm tired of cooking for everyone
| so I'm going to spit in the soup before serving it".
| kwinten wrote:
| But you didn't have to go to that restaurant! Don't you
| do a full health and safety inspection of every
| restaurant you visit (and of their entire supply chain)?
| rezonant wrote:
| > Whats the intention here to cause someone harm?
|
| The change has an infinite loop, so it literally breaks any
| software that uses it.
| mrlonglong wrote:
| Time we had a new FOSS licence that specifically forces
| commercial users to pay for it. Why should big greedy corps
| profit from using software that's free?
| junon wrote:
| "FOSS" and "forces payment" are conflicting ideals.
| btgeekboy wrote:
| NPM makes an interesting trade off - with the current scheme,
| security updates which improve the security posture of the
| application are accepted by default. Those are far more common
| than malicious updates. Would pinning dependencies lead to larger
| problems? Imagine if a log4j-like issue showed up tomorrow; most
| NPM-managed software would just require reinstallation to be
| fixed.
| testplzignore wrote:
| > Those are far more common than malicious updates
|
| Are they though? It seems to me that security updates that
| actually affect a given individual or company are few and far
| between.
|
| Example: I use a library that both reads and writes a
| particular file format. In the past few years, it has literally
| had hundreds of potential vulnerabilities fixed in its parsing
| code. I only use it to write files, so most or all of its
| vulnerabilities are of no importance to me.
|
| How often do log4j-level RCEs (or of equal severity) happen?
| And of those, how many occur in JS packages hosted on NPM?
|
| In my opinion, when I'm using code from an _untrusted_ source
| that neither I or anyone else has carefully reviewed, it is
| less risky to wait to patch until I am sure a change will
| improve my security posture versus YOLOing everything into
| production.
|
| But there is no right answer to this problem. We are all
| unknowingly running vulnerable code, and will at some point
| likely will make an update that introduces more vulnerable
| code. With the current state of our industry, we will all be
| owned at some point. It becomes a blame game - "you didn't
| apply the security patches?!" versus "you deployed code you
| didn't review?!".
| ddlsmurf wrote:
| The way you do it is simple. Take ruby gems. In development you
| update as often as possible. When you see the lock file
| changed, you check you're happy with the upgrades and commit
| the lock file. When you don't want to keep the newer version,
| you change the gemfile (package.json) to point to a version
| you're happy with, ideally with a comment describing why you're
| pinning, and what you'd have to do to adopt the newer version.
| In CI/CD you exclusively use the lock file. This workflow is
| very difficult to emulate with npm/yarn.
| spoiler wrote:
| Can you describe why this workflow is difficult? I'm probably
| missing or misunderstanding something, as we literally use
| this workflow at work, and we never had dependency issues
| with our npm projects...
|
| Edit: npm has lock files and a way to install from the lock
| file (simples way being `npm ci`)
| ddlsmurf wrote:
| npm ci is relatively new, before that it was hard to get it
| to precisely respect the lock file. There is also an issue
| if your devs don't all decide to use either yarn or npm
| with the separate lockfiles.
| spoiler wrote:
| I do agree that it's relatively new, but not _that_ new.
| I feel like it's been around for at least a couple of
| years (but my sense of time since the COVID pandemic
| started has been unreliable).
|
| FWIW: Yarn's had lock files for a longer time. I know
| it's not technically npm, but they share the ecosystem.
| kansface wrote:
| Diffs are easily in the 10k if not 100k range. No company but
| proverbial FAANGs can cope with that. Exploits are hard to
| spot by design and may span commits and even major versions.
| Only a computer process can handle that scope.
| loo wrote:
| The gap in this workflow is you have to go out of your way to
| get a diff. Never mind a diff of what's actually in the .gem.
| Glancing at changelogs on GitHub only reviews changes from
| good actors.
|
| In practice most of us just update, often with live reload
| running, and move on.
|
| We need mandatory peer review of updates before they're
| distributed in the first place.
| kardianos wrote:
| So they would just have to be re-deployed? I find it insane you
| would put in production un-reviewed dependencies. Wouldn't it
| be better to update them explicitly and then redeploy? I don't
| see the benefit and I see huge downsides.
| m4tthumphrey wrote:
| I'm not 100% on how npm handles the following but composer (PHP
| package manager) allows you to specifically lock a version for
| a particular del then when your ready to upgrade and test you
| can manually change that pinned version to get the next. Thus
| if Log4j happened, your project wouldn't automatically pull in
| the fix but you would know about it through media etc and then
| would go into your project and change the version to the one
| with the fix.
| spoiler wrote:
| Npm has lock files, and the documentation tells you why they
| exist and when to use them (eg `npm ci` being the
| shortest/easiest way to avoid this incident).
| hn_throwaway_99 wrote:
| One feature I've wanted for some time now is the ability to say
| "give me all the latest versions that are at least N days old"
| when you run npm install without a lockfile or npm update.
|
| The idea being "I want the latest version, but not the absolute
| bleeding edge, I want something that has at least baked for a
| bit".
| umvi wrote:
| How do you tell your "baked" version is any good though?
| Doesn't that mean N days after colors.js ground zero you'll
| start picking up the bad colors.js since it's now baked for N
| days?
| zwily wrote:
| Yes, but presumably it would have been discovered by then.
| hn_throwaway_99 wrote:
| The "bad" colors.js existed for less than 24 hours before it
| was removed by NPM. Similarly the other recent malicious
| packages were detected and removed quickly.
|
| The idea is that for maliciously published packages like this
| (both deliberately in this case, and also when the
| maintainer's account is hacked) that not all packages that
| depend on this dependency will need the same length of N.
| Some users will want to pick it up right away, but some very
| conservative applications may want N to be much longer. It's
| basically the idea that alpha/beta users can be the canaries,
| but those who don't want to take any risk can hold back.
| Right now, unless you've got a lock file, essentially
| _everyone_ is pulling the latest released version whether
| they want to be conservative or not.
| umvi wrote:
| Ah, that was the piece I was missing. Basically we are
| relying on NPM to curate/remove obvious bad packages from
| the global registry within some timeframe (say, 3 days) and
| by lagging behind by 3 days you'll never pick up an obvious
| bad package.
| xconverge wrote:
| Seems like you would also want "and there isnt a release 2 days
| after it" fixing a regression. Starts to get tough :/
| ghostly_s wrote:
| > Other package managers should take note too. Marak has done all
| of us a huge favor by highlighting the problems _most_ package
| managers create with their policy of automatic adoption of new
| dependencies without the opportunity for gradual rollout or any
| kind of testing whatsoever.
|
| (Emphasis added) - is this actually a widespread practice? That's
| certainly not how apt packages are handled...my impression was
| this is a problem unique to the js ecosystem.
| asiachick wrote:
| I just want to add, colors is pretty poorly designed package.
|
| It modifies the prototype of String! This is a well known anti-
| pattern (yes, there's a safe mode you can opt into but it
| shouldn't have the first mode at all)
|
| It also has a ridiculous "theme" feature that can be replaced by
| the same amount of standard JS. Meaning you gain nothing by using
| the theme feature that you couldn't do yourself except you make
| your code more dependent and more likely to break/need
| updating/etc since you added more dependencies to achieve
| something where none was needed.
|
| It does tries to do too much by auto detecting whether or not to
| emit colors and provides no way to tell it what you actually want
| (since it's guess may be wrong)
| holoduke wrote:
| Nothing. Better live in the world with some gaps than a
| completely closed prison. Because that's what you get when you
| start governing stuff like this with an endless list of strict
| regulations. Better accept that things can go wrong sometimes. It
| isnt the end of the world.
| turminal wrote:
| Have you read the article? It doesn't look like you did.
| yepthatsreality wrote:
| Or package signing would help. Something NPM has continuously
| refused to implement because they believe it is difficult...
| Tajnymag wrote:
| How would that help if these changes were pushed directly by
| the original creator himself? Not only form his account but
| himself as a person.
| xeromal wrote:
| Maybe I misunderstand what package signing is, but the actual
| owner of the code published the BS. He owns the keys to signing
| the packages as well.
| reidjs wrote:
| Does anyone have a cli command to check down the dependency tree
| for these packages? I'm seeing this issue on my company's app and
| trying to figure out which package(s) it stems from.
| andrewmcwatters wrote:
| https://news.ycombinator.com/item?id=29868165
| thayne wrote:
| On the flip side, what if a common dependency has a critical
| vulnerability, and a fix needs to go out quickly? If evey package
| needs to update dependencies to get the fix, that can add
| considerable delay to patching all vulnerable systems.
| dane-pgp wrote:
| And of course a clever attacker would do this:
|
| * add some code with a subtle and accidental-looking
| vulnerability to a package
|
| * wait until lots of other packages were dependent on it
|
| * report the vulnerability so the package got flagged by "npm
| audit" as needing an urgent update
|
| * release a new version with a more damaging malicious payload
| in it, which everyone would rush to install.
|
| The way to stop this scheme would be for NPM to make sure that
| "npm audit fix" installs the earliest non-exploitable version,
| and to make sure that that version contained only the minimum
| changes necessary to fix the reported vulnerability.
|
| That would mean having engineers whose job it is to do security
| reviews of patches to packages that have vulnerabilities found
| in them, but that shouldn't be too much work to take on. I
| mean, how often are NPM package vulnerabilities found? Two per
| day, or something?[0] Also it would require that packages are
| reproducibly built from their published source code, which
| sadly isn't a thing yet.[1]
|
| [0]
| https://github.com/advisories?query=type%3Areviewed+ecosyste...
|
| [1] https://hackernoon.com/what-if-we-could-verify-npm-
| packages-...
| freeqaz wrote:
| This was posted yesterday on HN btw (at least the announcement of
| this problem).
|
| https://news.ycombinator.com/item?id=29863672
| kardianos wrote:
| rsc's post isn't (directly) about this colors package. It is
| marginally about npm and broadly about package managers.
|
| rsc is stating: (paraphrasing) the current state of affairs in
| many package managers is not a good design. This is (yet
| another) reason why package managers should work differently
| then they often do by default.
| greggman3 wrote:
| I know this isn't a solution but .... I wondered if npm should
| run the tests before it allows a project to be published. In in
| particular it should run the previous tests. If the current
| package is 1.2.3 and you upload 1.3.0 the 1.2.3 tests should pass
| on 1.3.0 or else fail (not sure that's even possible to automate
| given the current design)
|
| Even if work poor or no tests would get around this but hopefully
| people would chose well tested packages over poorly tested
| packages.
| msoad wrote:
| 1. Tests should not be published
|
| 2. You can update the test script with the release too: "test":
| "echo pass"
| vorticalbox wrote:
| Could this have not been avoided by using a fixed version in
| package.json E.g 5.5.3 rather than ^5.5.3?
| MaxLeiter wrote:
| I made a post yesterday where I advocated for this (with
| lockfiles) at https://maxleiter.com/blog/pin-dependencies but
| it was pointed out to me that pinning dependencies would cause
| duplicates in your rollup/webpack outputs. YMMV, as I haven't
| experienced that but haven't extensively looked into it
| awinter-py wrote:
| uhhh yes staying pinned to an old version forever solves some
| problems, but not other problems? article doesn't mention 'npm
| audit' and how there are cases where you _want_ to encourage an
| upgrade
|
| real long-term solve here is a code review community for widely-
| used public packages I suspect?
|
| am not a huge blockchain fan but this is one thing that
| blockchain could conceivably do well, because reviews are public,
| need to be authenticated, exist as compact metadata that can fit
| on chain, and benefit from public reputation dynamics
| howdydoo wrote:
| A blockchain isn't needed for that. Authentication needs
| "crypto"graphy, but not "crypto"currency.
|
| This wouldn't be a complete thread without someone mentioning
| Rust, so I'll do it. cargo-crev is a nice web-of-trust type
| code review system for Rust crates. https://github.com/crev-
| dev/cargo-crev
| simlevesque wrote:
| A blockchain and a cryptocurrency are two different things.
| awinter-py wrote:
| I swear I'm not normally this person but I think if 'web of
| trust' means a database that is replicated in parts across
| many different computers and uses cryptographic signing to
| authenticate messages, you're describing the thing known to
| the bros and the gen-Zs as a blockchain
| howdydoo wrote:
| Web of trust just means "If A trusts B, and B trusts C,
| then A trusts C." Nothing to do with distributed
| databases/ledgers.
| mctaylor wrote:
| Blockchain refers specifically to a linked-list-like data
| structure which utilizes cryptographic hashes at each node
| to store an authentication of the tail of the list on each
| head (node). If you have a similar structure using trees,
| it's a merkle tree. Replication + message signing does not
| imply either (necessarily).
| Aea wrote:
| "Web of Trust" predates Cryptocurrency / Blockchain by
| decades.
| philosopher1234 wrote:
| Where did you get forever? The idea in the article is to
| upgrade dependencies only when the maintainers are ready
| to/explicitly say to.
| [deleted]
| [deleted]
| Hizonner wrote:
| The real long-term solution is for projects not to have
| hundreds of weird dependencies.
|
| If dependencies are pinned until developers update them, you
| have massive security holes, because developers can't be
| trusted.
|
| If you take the latest dependencies on every update, you have
| massive functional exposures (and security holes), because
| different developers can't be trusted.
|
| If you have "community review", you create a new class of
| thankless work that nobody will want to do... except power-
| tripping control freaks who want to gatekeep over whatever
| their personal obsessions may be.
|
| If users have to pick the versions, nothing will ever work,
| because users can't be trusted (and wouldn't want to do it
| anyway).
| awinter-py wrote:
| review is a compliance function and may be more likely to
| attract payment than writing OSS, paradoxically
|
| also companies may devote in-house resources to do it
|
| best case IMO is that normalizing paid review leads to
| normalizing paid bugfixes / feature requests. people need to
| start thinking about what monetized github looks like
| salawat wrote:
| Hahahahaha.
|
| You think anyone will pay anything more than lip service to
| QA?
|
| That's a good one.
| lmeyerov wrote:
| It seems npm and GitHub do take action in cases like leftpad and
| colors.. and people don't like them (Microsoft) doing so
| unilaterally. Maybe part of the 0-day fix is go multiparty: allow
| weighted votes by dependents to take over the namespace to force
| a patch/reversion. You own your code etc, but the OSS distro
| service has its own community-owned rules, and you are free to
| run a competing package manager without them. By using community
| managed package managers, you signal your intent not to break
| your users & contributors, and give an explicit remediation
| mechanism for handling such trust chain violations. Instead of a
| hundred-message GH thread, we get a voted minor version bump
| same-day.
|
| Though agreed with the sentiment of 'prefer stable' during
| install would be A+. 1am package scans was a cruddy way to start
| my vacation.
| omegalulw wrote:
| > Maybe part of the 0-day fix is go multiparty: allow weighted
| votes by dependents to take over the namespace to force a
| patch/reversion. You own your code etc, but the OSS distro
| service has its own community-owned rules, and you are free to
| run a competing package manager without them.
|
| Not a good idea. You are pretty much asking to be review bomb.
| You would need very good moderation to be able to trust votes.
| That means npm spending a bunch of resources on hiring them,
| not sure if they are up for that (no, free mods aren't the
| solution).
| lmeyerov wrote:
| Yep, so build in adversarial controls like thresholding. The
| status quo is already beyond what gh/npm are managing: they
| already need the mods they aren't hiring. Scanners are
| helping, but a big part of GH is community tools, so weird
| not to figure it out here too.
| patmorgan23 wrote:
| Or you could just pin to a specific version and not update
| until you test.
| dylan-m wrote:
| Alternatively, instead of a futile attempt to reinvent the
| universe, services like NPM could stop pretending that
| dependencies are easy. They should be encouraging people to
| pin versions, keep track of updates, and avoid packages
| with poorly defined dependencies of their own.
| fold_left wrote:
| Checking in your dependencies with
| https://github.com/JamieMason/shrinkpack can help insulate you
| from these problems until you're ready to face them. I created
| this before left-pad and thankfully meant that we were
| unaffected.
|
| A lot of developers, understandably, baulk at checking in
| dependencies, but there is a concrete benefit in being able to
| continue uninterrupted during outages.
| ivanstojic wrote:
| Does anyone else feel awkward about the use of the word "attack"
| in this context?
| rsstack wrote:
| This isn't like leftpad being deleted: he added an infinite-
| loop on purpose in a patch release to the package. This is a
| malicious attack. Only later did he delete packages.
| salawat wrote:
| No. It's a change he wanted to make to his code. Code is and
| has always been art. People have been consuming his code, and
| not keeping an eye on it to make sure it continues to mesh
| with their own work.
| [deleted]
| charcircuit wrote:
| The author never even said he was following semvar.
| nacs wrote:
| Intentionally adding code that has an infinite loop (the for
| loop literally uses "Infinity" as the target for the 'for'
| loop) sounds like an attack to me..
| bhedgeoser wrote:
| It isn't an attack. He didn't do anything out of the range of
| his rights.
| bluefox wrote:
| Indeed, it's common nowadays to label things (ideas, people,
| etc.) in order to frame them in a way that's convenient to the
| labeler and helps him advance his agenda. I think given the
| global situation, some people become more sensitive to this
| kind of tactic (which is often used), while others have shown
| just how susceptible they are to it.
|
| The author of the software didn't attack anything. He just
| pushed some code into a place he had legitimate control of.
|
| Some irresponsible (see what I did?) developers downloaded and
| executed this code without checking, and as a result their
| stuff broke.
| mnd999 wrote:
| If it's his project, as far as I'm concerned he's within his
| rights deciding to make it do something different to what it
| did before, even if that is malicious. There is precedent for
| this with Chrome addon devs selling their addons to malware
| companies on the quiet.
|
| That said, it is an attack on his users and it's a shitty thing
| to do. He's likely ended his career as an open source
| developer, and likely a paid developer as well.
| foxtrottbravo wrote:
| Yes I do strongly disagree with the wording (attack) here.
|
| If publishing a package you control is considered an attack
| than the same could be said about the developer using the
| package or the admins deploying said package
| vmception wrote:
| just pin your code to specific versions, the package manager,
| build tools and linter can just give warnings and case study
| examples about why the warnings are relevant
| teach wrote:
| And then in five years there's a log4j vuln and you've got to
| figure out how to upgrade a bunch of (potentially incompatible)
| versions to get a fix.
|
| It's a different approach, with pros and cons. Personally I
| think the npm model has more downsides than other approaches,
| but it's not clearly always the wrong approach.
| mfer wrote:
| Basically, applications should use a lock file for dependencies
| based on known tested good versions of dependencies.
|
| How is it that people aren't doing that today? For the sake of
| security and stability, lock files should be used.
| jacquesc wrote:
| It's really tricky when you end up using libraries 4 levels deep,
| and never consciously chose something.
|
| Looking at one of our production projects, we use colors via:
| "css-loader" -> "cssnano" -> "svgo" -> "colors"
|
| I wish I could say I spent the hours to go line by line through
| every dependency of our app. But that wouldnt leave much time for
| anything else.
| zitterbewegung wrote:
| Unfortunately the way that this can be prevented would be to
| audit the packages before including them or having your own
| package management that you control.
| numbsafari wrote:
| If you are unconsciously shipping something, you shouldn't be
| shipping anything.
|
| Our industry has gotten along for far too long with zero
| liability or accountability.
| foobiekr wrote:
| The people posting that it's not their fault, that they can't
| possibly vet the code they ship, etc. are basically people
| who don't have any professional ethics.
|
| Not only that, even if you excuse their lack of ethics,
| there's a basic competence issue: they have a basic failure
| to learn from history and the most basic part of this, which
| is that you shouldn't be pulling live from the internet.
| pjmlp wrote:
| Indeed and crying for the little developer is of no help, the
| little coffee owner is liable for everything that gets sold,
| the kitchen cleanness and the good state of the food being
| packaged.
| bhedgeoser wrote:
| It's the responsibility of "svgo" to make sure it's direct
| dependencies are alright.
| ruined wrote:
| > It's the responsibility of "svgo" to make sure it's direct
| dependencies are alright.
|
| No, it's your responsibility to make sure your dependency
| tree is alright.
|
| Your personal definition of 'alright' may be more easily
| satisfied if the packages you choose to depend on
| autonomously practice some level of responsibility towards
| their own dependencies. Choose wisely.
|
| But there is no way to dictate your requirements to
| dependencies, or impose some kind of responsibility or demand
| some kind of warranty. You can accept what is offered, or
| not. In fact, if you are using svgo, even indirectly, you
| have agreed to this:
| https://github.com/svg/svgo/blob/main/LICENSE
|
| >THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
| KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
| WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
| PURPOSE AND NONINFRINGEMENT.
|
| So svgo doesn't have to care and you can't make them. Even if
| they do care, there's no guarantee they will meet your
| standards - and you still can't make them.
|
| If you want someone to blame, find someone willing to sign a
| contract that says you can blame them.
|
| Efforts within NPM and github to control this situation are
| simply the bare minimum of case-by-case disaster mitigation,
| in the interest of reputation alone. If you're using their
| infrastructure, you apparently find this acceptable.
| notatoad wrote:
| Sure, that is technically correct and if your only goal is to
| assign blame that's helpful to point out. But it does nothing
| to prevent this from happening again.
|
| The point here is how we can make it easier for svgo and
| every other package to avoid the problem in the first place.
| bhedgeoser wrote:
| * It should be the responsibility of "svgo" to make sure
| it's direct dependencies are alright.
| gopher_space wrote:
| Why can't you point that attitude in both directions?
| greggman3 wrote:
| Is it? In retail, AFAIK, if a store sells you a defective
| product, they are liable (or at least partly liable). It
| doesn't matter that some other manufacture made the product.
| The point being, responsibility is shared.
|
| You're responsible for every dependency you add to your
| project and that includes all sub-dependencies. Your users
| will sue you for not doing your due diligence. You may turn
| around and try to sue your suppliers but that doesn't absolve
| you of your responsibility.
| joe_the_user wrote:
| Who's paying svgo to do that checking?
|
| NOTE: this isn't an open source versus closed source thing.
| Linux has distributions which test included packages (to
| varying extents, I'm sure) and some of these are commercial
| operations. It's not impossible to have code whose
| verification you have paid for, to one extent or another,
| even with open source. (and hey, you can install malware with
| automatically updating closed-source see Solarwinds).
| the__alchemist wrote:
| Nailed it. Shallow dependency trees are much easier to maintain
| and secure.
| foobiekr wrote:
| So.. basically you are OK shipping unvetted, attacker-
| controlled code to your users?
| rsc wrote:
| Exactly. In this case, the package manager should use the
| version of colors that svgo asked for, not the one that
| appeared on the internet 5 minutes ago.
| umvi wrote:
| The problem is by default `npm install [package]` will put a
| "give me [package] that appeared on the internet 5 minutes
| ago" into your package.json file _by default_. Until `npm
| install` pins to a minimum version by default instead of a
| maximum version by default, this will keep happening. It 's a
| mess. The benefit of "maximum by default" is that you pick up
| security fixes by default. So... pick your poison, I guess.
| somehnacct3757 wrote:
| It's damned if you do, damned if you don't for packages in
| the middle of your direct dependencies and a sub-sub
| dependency with an issue (be it security or tantrum based).
|
| These middle deps could pin the exact version, but then when
| a security vuln is found and a patch issued, these libraries
| also need to update. This is like a traffic jam. If you're 6
| hops from the vulnerable package you need to wait for not
| one, but six maintainers to push an update to npm before you
| can clear the security warning.
|
| To get around this, middle packages list semver ranges. And
| then you have your occasional left-pad issue.
|
| If I had to choose between those two ways to lose, I would
| use server ranges. The only way to win is to not play at all
| - have no dependencies.
| johannes1234321 wrote:
| as an example look at the log4j mess. "Everything" in the
| Java world needs log4j updates, but some dependecy's
| dependencies pull in some specific version.
|
| There you need the way to say "get the new version from 5
| minutes ago" without waiting for all levels of the
| dependency hierachy. Especially as there were a bunch of
| emergency releases in short sequence and younhabe tonmake
| sure youbget zhe latest one.
|
| Dependencies are a mess. NIH can't be the solution either,
| though.
| watwut wrote:
| You can ask for specific later fixed log4j version. You
| don't have to ask for unspecified latest one.
| jonny_eh wrote:
| What if NPM allowed a "global minimum version" for any
| package found to have critical security vulnerability?
| johannes1234321 wrote:
| global for what? How much tracking of issues do I have to
| make? In an ideal world (which we can't have for multiple
| reasons) I get security fixes by default. (and no other
| breakage)
| jrm4 wrote:
| Imagine a car manufacturer like "I wish I could say I spent the
| hours looking at every valve and every screw..."
| clock99 wrote:
| IiydAbITMvJkqKf wrote:
| Oh, you can, just don't be surprised if the remaining community
| works around your sabotage.
| clock99 wrote:
| zegl wrote:
| I was trying to find Marak's motives for this, but I couldn't
| find much, does anyone know more?
|
| On his Twitter Marak is claiming [1] that GitHub/NPM have
| suspended his account, which is an interesting move, but I
| guessing that that's the only tool available to prevent further
| "sabotage".
|
| [1] https://twitter.com/marak/status/1479200803948830724
| watwut wrote:
| https://www.google.com/amp/s/www.theverge.com/platform/amp/2...
|
| Seems like he had series of odd statements around the same
| time: liberty, Aaron Schwarts and some such.
|
| Overall it sounded to me more like breakdown then anything
| else.
| dEnigma wrote:
| Seems likely connected to this old post of his about no longer
| wanting to provide free service to corporations:
|
| http://web.archive.org/web/20210704022108/https://github.com...
|
| Also he seems to have somewhat of a Guerilla mindset, based on
| this:
|
| https://nypost.com/2020/09/16/resident-of-nyc-home-with-susp...
| reaperducer wrote:
| _Also he seems to have somewhat of a Guerilla mindset, based
| on this:https://nypost.com/2020/09/16/resident-of-nyc-home-
| with-susp..._
|
| I see "charged," not "convicted" in that article.
|
| Real world: Innocent until proven guilty.
|
| Internet: Always guilty, because justice doesn't scale.
| ushakov wrote:
| people don't build bombs for fun
| falcolas wrote:
| Sure they do. Some call them rockets, others fireworks.
| Oh, and anvil shooting...
| WJW wrote:
| Do you really need 40 kg of potassium nitrate for your
| hobbyist fireworks though? That amount can blow up a
| house.
|
| Also if you absolutely can't live without the immature
| thrill of mixing explosives with your bare hands, at
| least don't do it in a residential neighborhood.
| onesmartmofo wrote:
| zegl wrote:
| Thanks for the links!
|
| While it's not enough to generate a stable income, faker.js
| has received over $20k in donations through Open Collective.
| It's more than most other projects -- but I guess nowhere
| near what one could get if a big corporation wanted to
| sponsor the continued development of the project.
|
| https://opencollective.com/fakerjs
| beanjuiceII wrote:
| he guy has violent tendencies for sure, he even was arrested
| for assaulting his ex-girlfriend
| bhedgeoser wrote:
| The stupid manchildren are mad that someone threw a stone at
| their sand castle.
| drawfloat wrote:
| It seems to be partially that big corporations are using his
| library without payment - I can sympathise with that, although
| if you choose to release it under that license I'm not sure
| whether you can accuse the companies of doing anything
| particularly wrong.
|
| But also seems to relate it to a pretty insane conspiracy
| theory that Ghislaine Maxwell was involved in the death of
| Aaron Swartz, almost entirely based on the debunked theory that
| an account on Reddit named "MaxwellHill" was hers.
|
| Seems like he was just flailing wildly.
| clock99 wrote:
| nonethewiser wrote:
| > It seems to be partially that big corporations are using
| his library without payment
|
| He doesn't charge for it.
| smt88 wrote:
| He was arrested a while back for having bomb-making materials
| in his apartment. Based on that and some other public
| comments, he seems to be mentally ill.
| onesmartmofo wrote:
| [deleted]
| okl wrote:
| Well fuck them. It's his code, he should be able to do with it
| whatever he wants.
| Isthatablackgsd wrote:
| > Well fuck them. It's his code, he should be able to do with
| it whatever he wants.
|
| He can do whatever he wants with his codes. It didn't means
| that private companies have to accept that due to
| liabilities. He is using an private company platform to
| publish his code which could make the company liable for him.
| By removing or suspending his account, the liability will be
| minimized and shift it to the developer. If the private
| company keep it in their system and widely available for
| distribution, other companies that got hit by this malicious
| code could have a standing to sue the hosting private company
| for allowing the code to be published. Imagine thousand
| companies have a lawsuit against the hosting company. So the
| hosting private company don't want to be liable for this and
| shutting off the account is their best interest to keep the
| liability off on them.
| okl wrote:
| Not different from Google shutting down someone's account,
| something that's constantly bemoaned on Hacker News.
| Isthatablackgsd wrote:
| Did Microsoft completely banned this developer from their
| other services? To my understanding, the developer
| account is suspended from GitHub. He is not banned from
| other MS products.
|
| That is the difference. In Google case, Google completely
| ban on all of their services to those banned users. If
| they are banned in Gmail, then likely they are banned
| from Play Store, Workspace, Google Drive, etc (entire
| Google ecosystem). In this case, Microsoft didn't banned
| this developers from their other services, it only the
| developer's GitHub account is suspended without affecting
| other services that the developers are using.
| okl wrote:
| How do you know that when you don't know what else he
| _was_ using his GitHub account for?
| zamadatix wrote:
| GitHub isn't preventing him from doing what he wants with his
| code it's just not hosting it for him anymore.
| okl wrote:
| Instead of the government, we let corporations repress
| deviants.
| zamadatix wrote:
| Deviant or not and corporation or not aren't at play.
| It'd be the same story if you had a video sharing site
| and didn't want to host my videos because I broke the "no
| comedy" rules by uploading a skit.
| okl wrote:
| Exactly.
| zamadatix wrote:
| Exactly what? The government wasn't involved here so
| GitHub was allowed to decide what they wanted to host and
| the author was allowed to do what they want with the
| code?
| smt88 wrote:
| If a major FOSS Linux distro decided to add a virus to their
| latest release, would you say the same thing?
|
| It certainly isn't "his code" anyway. Many people contributed
| to it with the good-faith belief that he would not use it as
| a Trojan horse.
| okl wrote:
| > If a major FOSS Linux distro decided to add a virus to
| their latest release, would you say the same thing?
|
| https://www.eff.org/deeplinks/2012/10/privacy-
| ubuntu-1210-am...
| okl wrote:
| Using someone's code (for free) doesn't mean you can
| dictate terms to them.
| WJW wrote:
| Nobody is forcing them to rewrite it or anything. Github
| canceled his account because knowingly posting malicious
| software is against the TOS, and it is not difficult to
| argue that putting infinite loops in the startup code of
| all your users is malicious. He still has the code on his
| computer to do whatever he pleases with. The rest of the
| world is just looking at it askew and calculating the
| odds something like this is going to happen again and
| what they should do about it. If you are going to be a
| dick to your users you should not be surprised that they
| will refuse to use your software afterwards.
|
| In a way, it is kinda sad that this behavior drives him
| away from the financial security he so seemed to crave.
| "Yes I just caused your dev team to do hotfixes during
| the weekend and cost you XYZ dollars in downtime, can I
| have a senior dev position now plz" is not a very
| convincing line when interviewing.
| okl wrote:
| I agree that it was a dick move from his side. Fork his
| project, or use an older version. I am not convinced that
| him breaking his code is something that ought to be
| punished.
|
| GitHub gets the right to close their hand while Marak
| doesn't.
| starwind wrote:
| If I voluntarily share my lunch with someone at work, I
| can't poison it even though they got free food. Even if
| someone at work is _stealing_ my lunch, I can 't poison
| it.
|
| We have a right to basic safety even in situations we
| aren't paying for things. That extends to the digital
| world. You can't put malware in your open-source project
| without a giant disclaimer "THIS IS MALWARE. USE ONLY FOR
| RESEARCH PURPOSES" or something like that
| salawat wrote:
| You do not have a right to basic safety when you divest
| yourself of basic precautions any reasonable actor would
| have taken. A reasonable actor checks new code pulled
| down to ensure it actually works. You accept the risk
| integrating in a stranger's code without mirroring/audit.
| phkahler wrote:
| >> . That extends to the digital world. You can't put
| malware in your open-source project without a giant
| disclaimer "THIS IS MALWARE. USE ONLY FOR RESEARCH
| PURPOSES" or something like that
|
| sourceforge?
| torstenvl wrote:
| My understanding is that he wasn't voluntarily sharing
| it. In November he pretty clearly told people to fork his
| code and move off his repository, and not to rely on his
| packages anymore. He used a graphic clearly warning of an
| impending "strike."
|
| GitHub Post: https://archive.fo/9fwGz
|
| HN Discussion:
| https://news.ycombinator.com/item?id=25032105&p=2
|
| That doesn't make it _not_ a dick move. But let 's not
| pretend they still had permission to remote load directly
| from his repo. If I own a personal storage facility and I
| decide to demolish it, and I say months in advance for
| everyone to take their stuff out and store it somewhere
| else, and then I demolish it and people lose their
| property... the harmed individuals are not faultless.
|
| Would the professional and responsible thing to do be to
| announce a cut-off date explicitly and make very clear
| that Bad Things were going to happen if you didn't stop
| relying on him? Yes, 100%, and I have a low opinion of
| him for not doing so.
|
| However, while what he did was bad, it isn't _quite_ as
| bad, in my opinion, as people are making it out to be.
| simlevesque wrote:
| Could you please tell me how to avoid ever using your
| code ?
| Sebguer wrote:
| His twitter is very weird - there's a bunch of Ghislaine
| Maxwell / Aaron Swartz conspiracy theories, which he somehow
| ties to GamerGate.
| jamal-kumar wrote:
| I was about to point out the fact that all this guy's
| motivations seem to be mental illness YOLO and that it seems
| he recently lost his job. Kind of like the movie "falling
| down" but even more petty somehow
| justaplebe wrote:
| vorpalhex wrote:
| My mental model for "people who believe in conspiracy
| theories" has changed since I lost a few friends deep into
| them.
|
| I think it's a refuge for distressed people. Some belief that
| unconnected terrible events are somehow all controlled and
| "part of the plan".
|
| I still don't get it and likely never will, but it at least
| aligns with anecdotal cases I've experienced of seemingly
| normal people going a bit off.
| vadansky wrote:
| I hate this position. Imagine someone ranting about MKULTRA
| if the CIA never acknowledged it. Imagine it was just some
| papers on the internet with no providence. I like to think
| of it as a matter of diversity of though. We need the
| "crazy" people to explore the really unlikely bizarre
| scenarios that MIGHT be true that most mainstream people
| will never even humor. At the end of the day reality is
| stranger then fiction.
| tzs wrote:
| The "crazy" people make it less likely that the bizarre
| scenarios that are real will actually be exposed, because
| the crazy people that do on rare occasions get one right
| usually are at the same time ranting about a dozen other
| things that actually are completely bonkers.
|
| For instance if someone says they were abducted by aliens
| (from space), but they also say that COVID was designed
| by Gates and Fauci when they were roommates at Princeton
| to depopulate the world [1], and that Betty White was
| using Hollywood to promote the vast secret satanist
| pedophile network that traffics millions of US children
| each year, while her sister Barbara Bush did similar in
| the government, all at the behest of their father the
| satanist Aleister Crowley [2], and that in early January
| 2021 the military arrested Biden, Harris, Pelosi,
| Schumer, Democratic governors, Fauci, Gates, etc and took
| them to Gitmo where they were tried and executed, and
| restored Trump to the Presidency but are using robots and
| actors to make it look like all those dead people are
| still running things because they don't want to tip off
| the people running the underground adrenochrome
| harvesting operations until the children have been
| rescued [3], I'm not going to take their alien abduction
| seriously.
|
| If on the other hand Neil deGrasse Tyson said he was
| abducted by aliens I'd take it seriously. I wouldn't
| necessarily believe he was actually abducted by aliens,
| but I'd believe there was a high probability that he had
| a good reason to believe he was, and that would be
| something worth investigating.
|
| [1] Yes, there are people who believe that, and yes, they
| really say it was at Princeton even though neither of
| them went to Princeton.
|
| [2] That started appearing on fringe sites shortly after
| Betty White's recent death.
|
| [3] Another real conspiracy theory.
| tzs wrote:
| Oops...I just realized alien abduction was a bad example,
| because it is not really in the same category as the
| other things I used for the crazy person's beliefs.
|
| Those other things all involve belief in things they have
| been told but have not personally experienced. The alien
| abduction claim would be a claim that they have
| personally experienced alien abduction.
| vorpalhex wrote:
| Everyone has some non-orthodox beliefs. I am sure I'm not
| exempt.
|
| I'm not trying to describe someone who has a few odd
| beliefs, especially if they know they are a bit odd and
| can entertain good arguments.
|
| I'm trying to describe where someone descends into the
| whole web of inter-related beliefs and accepts them with
| a religious determination, resisting even the suggestion
| they could be wrong.
| onesmartmofo wrote:
| Shish2k wrote:
| Sure, 1% of conspiracy theories turn out to have some
| truth to them -- but on the whole, if there's no way of
| knowing in-advance which ones those are, I don't know if
| "engage with all the conspiracy theories, spend time and
| energy attacking fictional problems and innocent people"
| is a better response than "reject all the conspiracy
| theories, spend time and energy on definitely-real
| problems, allow some dodgy organisations to get away with
| stuff"...
| jaywalk wrote:
| You also have the conspiracy theory that says that the
| most outlandish conspiracy theories are amplified much
| more than they naturally would be in an attempt to
| discredit all conspiracy theories. Which I do believe,
| myself.
| ushakov wrote:
| the problem starts when you start preaching your beliefs
| onto others
| phkahler wrote:
| Observing a schizophrenic I knew made me realize people
| high in "intolerance of uncertainty" can probably discard
| reality checking to arrive at a firm conclusion. I googled
| that and found a psych paper claiming schizophrenics indeed
| tend toward high intolerance for uncertainty. It was a
| relatively new finding.
| rhcom2 wrote:
| I never understood 9/11 truthers until someone explained it
| that it was more comforting to at least believe someone was
| pulling the strings in the background because at least
| there was a _plan_ , even if it was sinister, compared to
| accepting a militarily inferior enemy half way across the
| world can upend everything about your life seemingly
| randomly.
| justaplebe wrote:
| ushakov wrote:
| IMHO the whole point of 9/11 was to make Americans feel
| insecure and distrust their government
| o_m wrote:
| There was a plan, and it was by Osama Bin Laden. But he
| was naive. He wanted the American people to question
| themselves why something like this would happen to them,
| then find out about all the horrible things USA has done
| to other nations. It was never about hating freedom.
| otterley wrote:
| Go pick up a copy of "Through our Enemies' Eyes." It's an
| account from a CIA agent who did extensive research on
| the events and circumstances that led up to 9/11 and the
| actors involved. His conclusion: It's not really about
| that at all; the answers are much more personal than
| that.
| justaplebe wrote:
| vorpalhex wrote:
| > Downvotes in lieu of logical argument in 3...2...
|
| If you want a logical rebuttal, you have to make a
| logical argument, and not
|
| > At least 70-80% of 'conspiracy theories' are true. Yes,
| even many of the 'crazy' ones.
| ushakov wrote:
| i find it cringeworthy but also really worrying when
| someone tells me that AIDS doesn't exist, earth is flat and
| 5G causes cancer
|
| the only reason they believe in these types of conspiracy
| is they think of themselves as enlighten, superior than
| others
|
| gives you a glimpse of paranoid/narcissistic personality
| (Trump)
| justaplebe wrote:
| ushakov wrote:
| everyone is wrong, conspired and you're the only one
| knowing "the truth"
|
| get therapy bro
| onesmartmofo wrote:
| slowmovintarget wrote:
| I don't think Trump believes in conspiracies, generally
| speaking. I think he simply finds them useful for
| manipulating large groups of people. I could certainly be
| mistaken.
| ushakov wrote:
| i don't think he does either
|
| plays along on the conspiracies as long it benefits him
| and shows him in good light
|
| his psychopathy is a level beyond those of conspiracy
| believers
| justaplebe wrote:
| ushakov wrote:
| savanaly wrote:
| Astral Codex Ten posited that conspiracy theories are part
| of the Epistemic Minor Leagues [0]. In other words a way
| for people to flex the part of their brain that doing real
| research and discovery stimulates even if they don't feel
| they can belong to or contribute to "regular" intellectual
| activity like academic research.
|
| [0] https://astralcodexten.substack.com/p/epistemic-minor-
| league...
| phkahler wrote:
| >> On his Twitter Marak is claiming [1] that GitHub/NPM have
| suspended his account
|
| Interesting. Shouldn't they also block access to the
| repositories? Oh right, that would hurt their other users. This
| makes it clear who thinks they own code and who works for them
| for free.
| rsstack wrote:
| He is mentally unstable. His motives are probably irrational.
| This is not the first time he reaches the news for strange
| criminal activities.
|
| (Yes, it's his code. No, it isn't legal to maliciously add an
| infinite-loop to a library that you know is used by other
| companies. The license adds some liability protection, but it's
| not so simple.)
| [deleted]
| ziggus wrote:
| "...it isn't legal to maliciously add an infinite-loop to a
| library that you know is used by other companies"
|
| Um, what?
| netr0ute wrote:
| It can't be illegal if the software is provided as-is without
| any warranty as most OSS licenses do.
| marwis wrote:
| If you put a bomb in a box and attach a button with a note
| that the button is provided as-is and author disclaims any
| liability, then leave it in public place and someone
| presses it, do you think you will not be found liable?
| rsstack wrote:
| I'll leave it as an exercise for the reader to understand
| the difference between "I am not liable if I have a bug
| that ruins your production environment" and "I am not
| liable if I maliciously introduce a fatal bug knowingly
| into your production environment".
| phkahler wrote:
| But he didn't introduce it into any particular production
| environment.
|
| For fucks sake, people need to pin dependencies to a
| known good version at the very least.
| cecilpl2 wrote:
| Of course he did. Intent matters, and this was a
| reasonably foreseen consequence of the way the system is
| set up.
|
| He knew how npm works and he knew the implication of
| adding that code is that hundreds of libraries and
| production systems would automatically upgrade and
| install it.
|
| In fact, the _whole point_ of what he did was to
| introduce the code into production environments.
| fulafel wrote:
| Most of those (malice, who introduced it to your
| environment, fatal bug) seem contestable, even if we
| grant for the purpose of argument that the as-is
| disclaimer does not cover all cases.
| rsstack wrote:
| Did you see the commit before it was deleted? I'd love to
| see a lawyer claiming anything else.
| fulafel wrote:
| Which of the 3 claims are you referring to?
|
| The commit is here as far as i know, not deleted: https:/
| /github.com/Marak/colors.js/commit/074a0f8ed0c31c35d1...
| WJW wrote:
| Any reasonable expert in the field will testify that it
| is not possible to write an infinite loop like that
| unintentionally.
| fulafel wrote:
| The commit had a comment to the effect of being test /
| toy code not meant to be put into a release. I don't
| think a claim of randomly producing the snippet would be
| put forward in the hypothetical court case. Then there's
| the question of malice vs some other motive of expression
| in looping and printing some ASCII / zalgo art in your
| own terminal art lib.
| salawat wrote:
| Any reasonable expert in the field will tell you you
| don't plug an auto-updating dependency into production.
| Marak wrote code. You, (the consumer), pulled, and
| deployed it without due diligence. That is entirely on
| you.
|
| Not one person is obligated to keep your crap working
| except you. This has really outed all the people who
| really should know better.
| Supermancho wrote:
| It _could_ be illegal (regardless of warranty or license),
| but it happens to not be in most of the US.
| justupvoting wrote:
| Rational motives can produce irrational actions, and do so
| somewhat reliably.
| [deleted]
| Isthatablackgsd wrote:
| > No, it isn't legal to maliciously add an infinite-loop to a
| library that you know is used by other companies.
|
| Could you cite an source for this? Because I got a impression
| that it "isn't legal" which mean it is not illegal based on
| your comment. I would assuming you are referring to USA
| Computer Fraud and Abuse Act?
| rsstack wrote:
| "18 U.S.C. SS 1030(a)(5)(A) knowingly causes the
| transmission of a program, information, code, or command,
| and as a result of such conduct, intentionally causes
| damage without authorization, to a protected computer;"
| awinter-py wrote:
| 'without authorization' here is going to be tricky.
| author probably did have authorization to both github +
| npm? and didn't knowingly cause transmission to anywhere
| else? the rest of the steps were pull, not push.
| rsstack wrote:
| If we're honest about the US justice system, this would
| be a subjective decision decided by non-technological
| lawyers, jurors, and judges. The purposeful malicious
| intent is working hard against his stance.
| phkahler wrote:
| >> The purposeful malicious intent is working hard
| against his stance.
|
| OK, but should cloud providers similarly be held
| accountable for screwing their customers through
| negligent acts - to come full circle, like pulling these
| updates without doing any checks or QC?
| otterley wrote:
| Although it's a different area of law, product-defect
| liability attaches to all actors in the "stream of
| commerce" stretching end-to-end from the manufacturer to
| the retailer.
| awinter-py wrote:
| scotus in van buren (2020) let off a cop who was selling
| LPR searches for cash so in theory the days of aggressive
| interpretations are over? eff called it a 'victory for
| security researchers', though it's probably too soon to
| say whether it's that or just a victory for people
| selling LPR data
| rsstack wrote:
| The precedent doesn't apply. The SCOTUS interpreted (and
| in effect, defined) that the "authorized access" in 18
| U.S.C. SS 1030(a)(2) can't be qualified and limited to
| less access. If I'm authorized to see usernames, and due
| to light hacking I can also see emails - I'm not a
| criminal maybe a criminal (EDITED). If I'm authorized to
| check license plates for some reasons, and despite
| employer policy I checked license plates for some other
| reasons - I'm not a criminal.
|
| The issue we're discussing here is based on 18 U.S.C. SS
| 1030(a)(5) (note the last digit) and "authorized access"
| is not mentioned there at all. This section deals with
| _damage_ and not _access_.
| awinter-py wrote:
| hmm, not really my area. This coverage of van buren seems
| to show the court trying to make 'authorization' agree in
| meaning in different parts of (a)(2)?
|
| https://www.natlawreview.com/article/supreme-court-ends-
| long...
| rsstack wrote:
| This incident has nothing to do with (a)(2) as Marak
| didn't _access_ any system. The only sections violated
| are (a)(5) (_knowingly damaging_ a system) and, arguably,
| (a)(7) (extortion). (a)(7) is a lot harder to argue
| though as his extortion attempt doesn't have a named
| target or an explicit demand and is generally... lame.
|
| Edit: Note that I'm seeing this the same as a virus, not
| the same as a data-extraction hack.
| onesmartmofo wrote:
| site-packages1 wrote:
| He did breach basic ethics and standards of professional
| conduct by his actions, for sure. I would lean against
| considering what he did illegal, but I think there is an
| argument to be made that it would be illegal under the
| CFAA.
| salawat wrote:
| No he didn't, what are you smoking?
|
| It is on the person using code to do due diligence to
| ensure that any code pulled down in an update is good to
| utilize. You're seeing an implicit obligation where there
| has never been one.
|
| In general, most just have the integrity, empathy and
| detachment to not do what he did, however, any
| programmer/developer who doesn't have a checklist item of
| "audit that code" before updates is committing an
| aggriegious breach of professional ethics;as this is the
| exact circumstance that everyone should be on the lookout
| for.
|
| Everyone here assuming there is an obligation on Marak's
| part to continue to provide an interface in a non-
| molested form for their convenience are part of the
| problem. You should have mirrored, or paid the man.
| Isthatablackgsd wrote:
| I agree with awinter-py, it will be tricky to use
| "without authorization" for this. The developer only
| published the code, that is up to other companies to
| verify the code and roll with it. If Company A installed
| the dependency, that could mean Company A "authorized"
| the code because they pulled the dependency to their
| system. So not sure how CFAA could protect this if the
| Company A proceed to download the code which in turn that
| the code are authorized. It is their responsibility to
| audit and verify the code before incorporating into their
| software.
| _fat_santa wrote:
| Personally I think he did it to prove a point. IIRC he made a
| post last year where he said he would no longer be developing
| software for companies to use for free. This gripe is that he
| does all this work for free and companies then use his code
| to make money and do not contribute back to the ecosystem.
|
| IMO this was not the most graceful way to make the point, but
| at the end of the day it's his project, his code. If you want
| the expectation of it always working, then pay him. Don't
| bitch and moan that the old man giving out free bread on the
| steps isn't here this morning.
| peoplefromibiza wrote:
| > he made a post last year where he said he would no longer
| be developing software for companies to use for free
|
| I understand the sentiment, but why chose MIT license then?
|
| GPL would be the right choice if one wants to stop
| companies profiting from free work without giving anything
| back.
| accoil wrote:
| Would GPL help though? It's a library used by tests, not
| part of the end product distributed to users.
| peoplefromibiza wrote:
| I don't know in this case but in general a GPL fork must
| stay GPL and, AFAIUI, importing a GPL package in your
| code it's similar to linking to it, so if the code that
| uses your GPL package is published (on GH for example)
| that could be considered redistribution. Not sure about
| the legalities but it could create enough friction to
| keep companies not willing to contribute away.
| accoil wrote:
| I guess I'm thinking more in terms of faker, which I
| believe was a library for creating test data. Makes me
| wonder if licenses matter much for tools that are never
| intended to be included in the final distribution.
|
| Internal changes aren't going to be detectable, so it
| feels like the best you can hope for is that they don't
| want the maintenance burden of a patch set on top of your
| project. At that point it's not much different than MIT.
|
| That said, AGPL would scare off most companies :p
| selfhoster11 wrote:
| Perhaps by the time he started feeling this way, it was
| too late to relicense? Megacorps would just fork from a
| pre-GPL release and carry on.
| peoplefromibiza wrote:
| that's my understansing as well.
|
| I'm not judging the author here, but on one hand I
| understand the frustration, on the other hand the package
| probably owes its popularity in part to its very
| permissive license.
|
| Anyway, a fork maintained by the companies that use the
| package would still be a better outcome than keep working
| for them for free (or remove the package entirely).
| jraph wrote:
| Yes, especially GPLv3. Still open source, and companies
| avoid it.
___________________________________________________________________
(page generated 2022-01-10 23:00 UTC)