How is it not a legal issue to intentionally DOS customers servers? I would send a complaint to the California DA’s office for hacking; the laws against which in CA are very liberal.
Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
161–170 of 1001 posts
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#162Earlier quoted context omitted.
> I don't want that level of control over other people's projects, it's scary How far do you take this though? The average GNU Linux distro ships with a whole pile of packages already installed, from a multitude of different authors.
Packing is most of the point of a distro. They are specifically taking on that responsibility. They also have a better perspective to handle overall compatibility. In a sense you've pointed out the alternative to having the programmer handling the packaging -- having some third party package and distribute. And this separation of responsibility turns out be almost always be a better solution. Distribution and coding…
Given that Debian (and its descendants...) packages a shitload of npm packages, it's a wide stretch to say there is more QA for these packages from the Debian side than there is from the npm side.
The one thing that Debian provides is that in the case there is a security issue, admins worldwide only need to do "apt update && apt upgrade" and they are safe, without having to check all of the software that runs on their servers (as long as said software comes from Debian, that is!).
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#163Earlier quoted context omitted.
> What exactly does colors do? A picture is worth a thousand words → https://i.imgur.com/inxA7Pg.png The library inserts ANSI escape sequences [1] between the text you want to colorize in order to, well, colorize it ¯\_(ツ)_/¯ Many people are obsessed with colors in the Terminal, and so, they reach out to libraries like this. They exist in every major programming language ecosystem, even though colorizing text is as s…
Why wouldn't everyone roll their own solution? Doesn't seem to be a huge thing to me, but I could be wrong...
exhibit A
> even though colorizing text is as simple as writing this \x1b[48;5;011\x1[0m
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#164NPM dependencies go brrrrr again. Long live leftpad and the lack of stdlib!
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#165Anyone knows what the author meant by the "LIBERTY LIBERTY LIBERTY" message? It's unclear if it's referring to current authoritarian turns in our western world, big corps using his software for free, or something else.
The author of this package was caught with 50lbs of Potassium Nitrate (in the middle of NYC) and a bunch of materials on making bombs and booby traps when his apartment caught fire: https://abc7ny.com/suspicious-package-queens-astoria-fire/64... https://www.qgazette.com/articles/more-charges-possible-for-... https://nypost.com/2020/09/16/resident-of-nyc-home-with-susp... He might have been the unibomber in training.…
No post body was provided.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#166I'm not sure what this is going to achieve for Marak but I can't help but sympathize and I can only imagine he is at the end of his patience - and who can blame him?
The Retool people who decided to literally fuck this guy with his own project should be ashamed of themselves.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#167It's time for someone to make a Redhat, but for "safe" open source software libraries. My big enterprise would sign up for it in a heartbeat. We'd pay for access from an alternative NPM registry where everything is at least semi-vetted - someone at least looks at diffs before new versions get updated and made available. Sure, the "safe" repo wouldn't have as nearly as many packages as the main NPM repo, but if it had the most popular packages that's probably fine.
If I'm developing an app and wanted to use something outside of that "safe" registry, maybe I could, but I'd have to have a longer conversation with my enterprise's security org about why I'm using some new package that's not in the "safe" registry - and I'd probably have to pin or import it into my org's private repo.
It's up to package authors and this new Redhat-ish company that manages the "safe" repo to figure out how to split revenue back to package authors. The new company is definitely providing a service and should get to keep a cut, but hopefully there's enough left over to give some to the package authors - and that's incentive enough for the package authors to want to get their code included in the "safe" repo.
My company's security org is doing code scans/static analysis and version tracking and software BOM work of everything we're building, but ultimately none of this makes sense if I as an app developer can just add whatever I want and it's assumed to be safe if it passes the scans and doesn't have a CVE listed somewhere. We'd happily pay if someone was willing to try to vet packages (and take on some liability if they're wrong)
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#168This is why you pin all dependencies and upgrade (and test) when it's convenient for _you_, not when the author pushes a new version.
The only way to prevent this is to pin the actual commit. Because the meaning of the semantic version numbers is up to the package maintainers in most packaging systems. And even then you need a way to source exactly that version without relying on the original author's cooperation. Pinning all dependencies to this extent is extremely inconvenient. More inconvenient, arguably, than to deal with this shit once in a wh…
Then the package manager should be changed to make it more convenient.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#169My sense is that it’s time to evolve licensing such that wealthy major consumers of packages that have become somewhat essential are naturally paying a licence fee. The problem is not in what the code does it’s a problem with the agreement for use.
When you publish free software you give it away as a gift. That's the point. Expecting compensation for a gift is the error.
It's not the original gift that is the problem, all maintainers start very happy early on but keeping software up while adding more features is costly, someone needs to pay an it's almost always paid by the maintainer in terms of free time.
If you intend to keep it as the original gift, it will be called abandoned.
Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps
#170Earlier quoted context omitted.
Actually in attempting to answer my own question, on other platforms like YouTube and Medium, popular content receives monetary support by virtue of being popular. What if this was addressed at the “platform” level, I’m thinking the package manager here, NPM. If npm had paid plans that would essentially mop up larger corporations they could then auto-distribute funds Spotify style based on “number of listens”. I’d pe…
> If npm had paid plans that would essentially mop up larger corporations they could then auto-distribute funds Spotify style based on “number of listens”. This seems like a pretty decent idea…
Until there's enough money in the pot that making your packages seem very important happens to be a productive use of one's time. At that point, you have to start dealing with fake downloads, dependencies added for no reason to somewhat more popular packages that aren't paying much attention... and suddenly you need to take money from the pool to pay for your fraud prevention team.