941–950 of 1001 posts
While I disagree with his move. 1.It is totally in his prerogative to mess up the package he manages, but not to install into it malware. I am on the fence if this would count as malware. (Because of the open loop, but my leaning is that this is not malware.) 2. Github is, IMO, breaking any trust that I might have had by assuming control of the package, removing the last commit and keeping it online. If they feel the…
Should I get paid for my multiple contributions to faker (I don't think I should)? I've submitted several PR's for generating data all of which were accepted. Even back then the maintainer was barking about money... Honestly the project would be better off forked. He did not write this library entirely by himself, at this point I just see him as holding other committers contributions as hostage. It's a bad look, why…
> at this point I just see him as holding other committers contributions as hostage No he's not, and you're just trying to be outraged. Just fork the code if you don't trust him. Oh, but you don't want to take his place as the maintainer? Maybe deep down you know that there's still a difference between being in charge and submitting the occasional pull request? Your actions contradict your words here.
Earlier quoted context omitted.
> It's a bad look, why would anyone want to deal with him after this stunt is beyond me. The maintainer appears to be unwell: https://abc7ny.com/suspicious-package-queens-astoria-fire/64...
> Squires is a software developer and early Bitcoin investor Or maybe his crypto bet went in a poor direction...?
Earlier quoted context omitted.
Security auditor here. Every time I see a client importing unsigned code with no evidence anyone they trust has reviewed it, I flag it as a supply chain attack vector in their audit and recommend mitigations. Some roll their eyes, but I will continue to defend it is a serious issue almost every company has, particularly since I have exploited this multiple times to prove a point by buying a lapsed domain name that mi…
If we are willing to admit that repositories like npm are useful, what can be done to mitigate these issues? Is there some tooling we can build?
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.
> I've never heard of GitHub enforcing the multiple accounts thing, FWIW correct they don't enforce it but they make it such a royal PITA to switch accounts that I eventually gave up trying. They don't have an account switcher like Google etc. > As for alternatives, check https://sr.ht thank you! Checking it out. Edit: it seems that sr.ht is not self-hosted though? I can see the link to create an account but I can't…
> correct they don't enforce it but they make it such a royal PITA to switch accounts that I eventually gave up trying. If you are ever in need again, Firefox containers are great for this. They also allow you to bundle other corporate accounts, so you don't need any site-dependent switchers at all. > Edit: it seems that sr.ht is not self-hosted though? I can see the link to create an account but I can't find instruc…
But at the end of the day, sometimes I end up using my personal computer to file PRs that were inspired by a work situation. If for no other reason than at work I want my work email associated with commits, but I don't want to accidentally push it up to github.
This sort of stuff is why I'm for larger standard libraries. Design-by-committee issues are one thing, but ultimately each library maintainer having to go out there and sell themselves at this atomized creature, instead of being able to group together resources, means we're paying over and over for base functionality, with the willpower of people with good intentions. This might be controversial, but I feel like the…
Problem is that package-lock.json files in node don't compose. I can't pull in a library that locks other libraries to a specific versions for me. It is possible there's another solution presented by DVCS, but it's not clear to me if it actually avoids the set of problems illustrated here or just dresses them up in different outfits.
Earlier quoted context omitted.
These sorts of "security" measures kill productivity and ultimately accrue (along with others) to the point where your organization moves so slowly that its lunch gets eaten by upstart competitors who aren't burdened by self-imposed make-work. I've seen it happen.* EDIT: * While working in infosec, I'll add.
Are you mitigating supply chain attacks otherwise? If yes, how?
1. Robust build and deployment processes. Locked-down build servers, proxied/cached package registries, locked dependencies, automated dependency upgrades, tests, rollbacks, etc. Pretty much exactly what you need to mitigate unexpected breaking changes in dependencies, regardless of whether they're security risks or not.
2. Comprehensive dependency inventory. List of all your dependencies, where they're used, what vulnerabilities they're affected by, various other metadata, automated threat-hunting, manual review and annotation.
Trust but verify. No need for developers to fill out forms, wait on your (context-free) approval, resort to implementing worse versions of things themselves because they don't want to jump through hoops, etc.
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.
> 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. I think it follows from two things: 1. We use open source software for everything. This is also true of our dependencies, so we get hundreds or thousands of transitive dependencies. Many of which are presumably written by dogs, because (i) no one…
This leads to some thoughts on statically-compiled applications; while they might have some vulnerable dependency, I suspect that it's harder when the attacker is limited to the app's "baked-in" functionality that defines how those dependencies get used.
Edit: Also, I should note that while I would greatly prefer, and do advise, that they base their environments on minimal OS distributions, this seems rare. The base system patching would be much easier to manage if it started from some BSD-like minimal state, or Alpine Linux, and included only what it needs. Instead, any infrastructure vulnerability assessment leads the teams to chasing down numerous patches in things they have, but never use.
Earlier quoted context omitted.
You can pin the direct dependency, but what if the packages you depend on don't pin their own dependencies? The standard (default behavior) is to use ^, which will automatically install new minor versions. Package.lock helps, but there's no sane way manage upgrades. Just running "npm audit fix" could result in pulling down a bad package.
If you pin your direct dependency doesn't that mean it can not change versions of its dependencies? The same version number of a package should always link to the same version numbers of both its direct and nested dependencies. No?
NPM is highly optimized to make sharing code as easily as possible, but that comes at a heavy price.