201–210 of 336 posts
I bet $101 that we find something similar in the wild in the next 12 months as the maintainers start to look at each other's past commits with suspicion.
Earlier quoted context omitted.
I hope Open Source maintainers and the big companies get the message -- they need to change the financial outlook of open source maintaining.
I think the message would more likely be "don't use open source and pay for closed source" than "give money to open source and cross your fingers that it does something".
I bet $101 that we find something similar in the wild in the next 12 months as the maintainers start to look at each other's past commits with suspicion.
Just look at any critical, yet largely unknown codebase with very few maintainers.
This represents a massive failure of the Open Source model and it's worth thinking carefully about as more and more people advocate for fully open source AI models. People could spend a lot of time on token safety features only to have them backdoored by a sneaky PR and it's not clear what level of damage this could cause in the near future.
Isn't it the opposite, though? The whole thing was caught precisely because it was open source. Sure, you can argue that the vulnerability was introduced by a contributor, but what prevents the same thing from happening in a private repository, perpetrated by an actual employee? Especially if you consider that many vulnerabilities can be introduced with code more likely to pass as legitimate mistakes.
Are we ever going to figure out who Jia Tan is?
I've been going through Wikiepdia's list of countries by GDP and trying to think about what the poorest country is that could pull it off in the normal course of business, and the poorest country that could pull this off if the leader decided it was important and was willing to push a little. I think there are at least a hundred countries in the later category. https://en.wikipedia.org/wiki/List_of_countries_by_GDP_(…
My bet is on the Vatican City elite hackers.
(It's sophisticated, but it could have been done by a "commercial hacking group" for other purposes, especially to sell; if this had gotten into live RedHat systems it would be quite the valuable 0day.)
Earlier quoted context omitted.
I think the message would more likely be "don't use open source and pay for closed source" than "give money to open source and cross your fingers that it does something".
Either way, it gives more jobs and $$$ to software developers in general. I'm fine with both :) Just imagine how many more jobs will be created if every large company decides to roll their own stuffs. A lot are actually doing this, but not enough.
Are we ever going to figure out who Jia Tan is?
Earlier quoted context omitted.
Arch, Gentoo and openSUSE Tumbleweed are hardly the world.
Arch and Gentoo were also not supported, although the code shipped, because the exploit explicitly checked for RPM- and deb-packaged distros. Suse is RPM based, but don’t remember whether the check was for the utilities or another method — Suse uses zypper for package management, as opposed to yum/dnf on the far more popular RedHat-based distros, so it depends how the exploit checked.
test "x$RPM_ARCH" = "xx86_64"Earlier quoted context omitted.
> Like, meeting someone at several dev conferences should be a requirement at the very least. This is utterly and completely unfeasible. Most open source maintainers, especially those that are struggling and are pressured to hand-off maintenance, don't have the time, means and will to travel to meet up with prospective co-maintainers, not just once but multiple times. In practice it would just result in projects gett…
Intelligence agencies mastered fooling people about their bona fides in person a long time ago. Meeting someone in person will stop casual individuals who just want to crash the project for the lols or some other personal-level reason, but it would have been barely a bump in the road for this clearly-nation-state-level attack.
We actually know who poisoned Alexander Litvinenko and what they're up to today, for example.[0]
What I haven't seen discussed much is the linking mechanism that allowed the lib to hook into RSA_public_decrypt. Plenty of talk about what could or could not be achieved by even more process separation and the like, but little about that function call redirect. Could it be possible to establish a way to link critical components like the code for incoming ssh with libraries in some tiered trust way? "I trust you when…
systemd merged a change to using dlopen for compression libraries recently https://github.com/systemd/systemd/pull/31550 which is a safer linking method in that sense.