451–460 of 1001 posts
GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724
If that is true it's an outrageous overreaction by GH. Are they now gatekeeping the kinds of code changes you can make to your own repo?
I don’t understand the mindset of open source developers who dedicate significant time energy and life to free software, unless there’s a tangible, quantifiable advantage to doing so. That advantage may well be indirect such as reputational or learning. I just don’t grasp why people do it for nothing, to the advantage of large companies.
Because it's fun ya mook. That's it. That's the reason. It's fun to tinker. It's fun to put things out there into the ether. It's fun to exercise the brain and try new things and learn new ways to do things and publish things. The second it stops being fun, we stop.
Discussions now are about how you shouldn’t run your own server, and you should use popular stuff so you can speed up development and get your startup going.
I mean, I know about ycombinator and all. But it doesn’t seem to truly encompass the hacker spirit, if you ask me.
It'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…
AITA for thinking that if you develop open-source software and your license permits anyone to use it for free, then complaining about no compensation is not a valid complaint? I totally understand that billionaire corporations use software like this for free. But the software maintainer has explicitly allowed _anyone_ to use it for free. If you don't want them to use it for free, license it as such. What am I not see…
Just reply here and I'll see them.
Earlier quoted context omitted.
I don't understand why. It's his code to break if he wants. But I guess when you use a social media service to host your code these are expected and normal results.
> It's his code to break if he wants > I don't understand why If he can break his code because he is the owner then shouldn't the same reasoning apply for Github suspending the account?. It is their website and their rules. Keep in mind Github owns npm and the author has published a malicious package to npm which has 20 millions of downloads so I'm not surprised.
The software industry doesn't have any standards about how to publish or consume software, and that leads to problems like these (not the conflict over OSS, but the ability for random upstream software to randomly compromise thousands of other projects). We all live in this 'wild wild west' of software that has no guarantees of quality or safety or rigor. We could really use a regulated license for software developme…
> The software industry doesn't have any standards about how to publish or consume software, and that leads to problems like these (not the conflict over OSS, but the ability for random upstream software to randomly compromise thousands of other projects). The publishing side is irrelevant. Anybody can make any package available for free on the internet. The unwillingness of some private businesses, often billion dol…
Businesses don't really use open source to cut costs. Most businesses don't even know they're using open source. The business hires engineers and tells them what they want built, and the engineers choose to use open source, because they're lazy and it's quicker than trying to get proprietary vendors approved and licensing costs included in budget forecasts. Maybe some tiny companies that have no money really need to use FOSS, but the majority of businesses pay for software when they need to, they don't mind.
Earlier quoted context omitted.
A key difference with Maven projects is that you specify exact dependency versions instead of “always use latest” or some variant of that, as is pretty common in the Node world.
This is not necessarily true, there are version ranges: https://www.baeldung.com/maven-dependency-latest-version Admittedly, I don't think it has nearly as wide a usage as it has in the NPM world. Dependabot (I know I'm not the first to mention it, here, today) is probably more of a factor. Still , it strikes me that this sort of "attack" (or mishap) is exceedingly rare in the Java ecosystem, while it's pretty common…
Earlier quoted context omitted.
How about using dependencies but pinning the version and only updating if you know what the update contains? I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommended practice.
> if you know what the update contains? I think anyone who thinks they're doing this is fooling themselves. You can review code for accidental vulnerabilities but if someone is trying to slip in a backdoor it shouldn't be hard to do so in a stealthy manner. The reality is that the entire dependency concept is just broken. There is an implicit trust that all dependencies are equally trusted. Your logging package is ju…
Earlier quoted context omitted.
The tool should take some blame here. I agree that it’s ultimately the developers fault for allowing code to be automatically injected from not fully trusted sources on minor updates, but the package manager makes it way too easy to do. For example, when I npm install a package, it defaults to specifying a semver compatible version in package.json, rather than doing the secure thing and pinning a version. But whether…
> it defaults to specifying a semver compatible version in package.json, rather than doing the secure thing and pinning a version Note that if you have a package-lock.json (which you will by default), it will prevent any surprise updates even within the semver range specified. You have to manually run `npm update` to get the latest versions that match your semver. Personally I think this is the best middle-ground.
To make this work correctly, you need to do `yarn install --frozen-lock-file` or `npm ci`.
It’s absolutely _insane_ that this is the case. Gemfile.lock, Cargo.lock, and every other lock file format that I have used in packaging does this correctly.