101–110 of 353 posts
The Jigar Kumar account should be treated with extreme suspicion. It seems like it was part of a social engineering attack.
Earlier quoted context omitted.
> The SaaS/cloud/etc. companies themselves should fund the projects they depend on. There is a bit of a free rider problem it seems.
Noooooooo you can’t ask them to pay! You’re supposed to do this for the good of the community only! They ought to be able to take whatever you do and resell at their leisure, after all you made it open source!
Earlier quoted context omitted.
1) Debian includes this downstream patch, also. 2) A potential explanation for "why now" is that systemd DID prevent these dependencies from loading automatically in a patch one month ago [0], and the patches to lzma enabling the backdoor merged a few days later, followed by (as we know) an immediate and somewhat heavy push to get distros to upgrade driven by sockpuppets. It could be a total coincidence, or it could…
I believe they were talking about sideloading a binary tarball instead of building and repackaging. Choosing a distro is nothing but choosing where you place your trust. I can understand debian cutting corners here and there. But RH have little excuses with the money they make. Yet, even a superficial analysis, show them to be less trustworthy than the anime-avatars maintaining gentoo or arch.
>>> Software developers are not fungible cogs that you can swap in and out at will. I am thinking a lot about this. One of the issues is scale and proof. I suspect that I am interested in introducing gated ability to comment / participate in a community Say for example github introduces “gates”. The first might be add a test to the test suite that generates a haha of the version number and test output. Then adding th…
I mean, the idea of commitment -> privilege isn’t bad. But it’s got nothing to offer in the story of xz.
If I were a chinese hacker trying to do something evil, why on earth would I use a chinese handler/username? Wouldn’t it be better to use an English/European name to gain (even more) trust from open source maintainers? On the other hand, if I were a non-chinese hacker trying to do evil, then using a chinese handler does make more sense (China is evil, blah blah blah)
1. Might not have the vocabulary to express themselves correctly
2. Not understand the nuance and connotations that their word choices imply
I've seen my colleagues get frustrated in meetings while simulatenously having to assume good intent.
Choosing names like the bad actor(s) did gives them an advantage in this scenario.
Earlier quoted context omitted.
> It made it to production, for a long time Did it? At least in Debian, where it was found in the first place, it only existed in sid/unstable and I think perhaps in testing. It never made it into stable which is the only thing you should be running on a production system. I think in Fedora it was also only in a testing or RC of the next stable version but I'm not sure. Also unsure about others. I have seen several d…
I don't know specifics either, but Debian stable has years-old packages, so I'm not sure if it's a good indicator of how widespread this got. If it's in the latest Ubuntu release, I'd say it's pretty successful.
The end goal seems to have been to get it into the LTS releases of rhel and Ubuntu. Since this was a valuable it's probably something kept around for when other methods fail. I doubt it would be used before the really valuable systems are compromised (rhel and Ubuntu in cloud and governments)
I do sometimes wonder if by trying to be "nice" to users and try to see the best intentions of commenters, many developers waste huge amounts of mental energy. For context, I've really only worked on "fun" side projects, namely emulators and game remakes, where I've explicitly avoided any mention of donations or similar. Both as it's intended to be a distraction from my job, not become part of it. And generally avoid…
Earlier quoted context omitted.
"I don't feel like it, if it's important to you then feel free to fork". That's really all that's needed. that's much harder than it sounds. having someone fork your project can give you the feeling of loosing control over the project as potentially all your users might go with the fork. that fear is often strong enough to push yourself to do things that will avoid a fork. it's a desire for harmony and a fear of conf…
You're right of course, but there are cultural norms and expectations at play here, which I feel need to be modified somewhat. And that doesn't really change that things really are that simple, kind of. How do you stop smoking? By not lighting up any cigarettes. Of course it's not that simple, but ... it also kind of is.
this is an important observation.
a change of culture is really what is needed here, because it implies that not only maintainers change their behavior, but everyone involved, and the question is not so much what any individual can do for themselves, but how we can help others with that change and spread it
I do sometimes wonder if by trying to be "nice" to users and try to see the best intentions of commenters, many developers waste huge amounts of mental energy. For context, I've really only worked on "fun" side projects, namely emulators and game remakes, where I've explicitly avoided any mention of donations or similar. Both as it's intended to be a distraction from my job, not become part of it. And generally avoid…
>Our no-longer-reasonable requestor also offers a suggestions. Notice there is no offer to actually help. Help in maintainship how? Patches had already been made and were awaiting to be reviewed and merged. This was up to the maintainer to do and requestor couldn't help with it.
> Help in maintainship how? Pay.
Time is another factor. It takes time to maintain software, improve the codebase, add features, etc. Then there are the other tasks such as answering questions, reviewing PRs, triaging bugs and feature requests, etc.
So getting more contributors, people to assist with bugs and bug investigations, etc. is arguably more important. Especially projects developed by a single person, or a small number of people. That's the avenue that opened up this attack.
It is easy to get burned out implementing features that end up being more complex than expected, interacting with users that want different things from a project, and having a growing list of issues and PRs. That's the scenario that happened with xz, and is common with popular software that is maintained by a solo developer.
The other aspect to this is the direction the maintainer wants to take the project in. If another maintainer has a different direction in mind, that's going to cause tension.