381–390 of 1001 posts
Earlier quoted context omitted.
I would be curious if their commits could be analyzed for patterns that could then be used to detect commits from their other account
One thing that is annoying is that many open source projects have been getting "garbage commits" apparently from people looking to "build cred" for resumes or such. Easier and easier to hide this junk in amongst them.
Another interesting data point: about 2 years ago there was a clear pressure campaign to name a new maintainer: https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.h... At the time I thought it was just rude, but maybe this is when it all started.
I think its much more likely this was not a bad actor, given their long history of commits. It's a known fact that China will "recruit" people to operate them. A quote: > They talk to them, say my friend, I see you like our special menu. Are you from China? Are you here on a VISA? Do you have family back there? Would you like your family to stay alive? Is your loyalty to this temporary employer or is your loyalty to…
I think we should seriously consider something like a ts clearance as mandatory for work on core technologies. Many other projects, both open and closed, are probably compromised by foreign agents.
> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. The systemd notification protocol could have been as simple as just writing a newline to a pipe, but instead you have to link to the libsystemd C library, so now security-critical daemons like openssh have additional dependencies like liblzma loaded…
> The systemd notification protocol could have been as simple as just writing a newline to a pipe It basically is. libsystemd links to liblzma for other features not related to notifications. (The protocol is that systemd passes the path to a unix socket in the `NOTIFY_SOCKET` env variable, and the daemon writes "READY=1" into it.)
Which is pretty emblematic of systemd's primary architectural fault!
Earlier quoted context omitted.
Couldn't the autoconf soup be generated from simpler inputs by the CI/CD system to avoid this kind of problem? Incomprehensible soup as a build artifact (e.g. executables) is perfectly normal, but it seems to me that such things don't belong in the source code. (This means you too, gradle-wrapper! And your generated wrapper for your generated wrapper. That junk is not source code and doesn't belong in the repo.)
Yes, it's usually regenerated already. However even the source is often pretty gnarly. And in general, the build system of a large project is doing a lot of work and is considered pretty uninteresting and obscure. Random CMake macros or shell scripts would be just as likely to host bad code. This is also why I like meson, because it's much more constrained than the others and the build system tends to be more modular…
Build systems can even have undefined behaviour in the C++ sense. For example Conan 2 has a whole page on that.
> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. The systemd notification protocol could have been as simple as just writing a newline to a pipe, but instead you have to link to the libsystemd C library, so now security-critical daemons like openssh have additional dependencies like liblzma loaded…
One of the objections that many people do not understand, is that systemd adds complexity. Unnecessary complexity. Boats full, loads full, mountains full of complexity. Yes, there are things delivered with that complexity. However, as an example, sysvinit is maybe, oh, 20k lines of code including binaries, heck including all core init scripts. What's systemd? 2M lines? It was >1M lines 4+ years ago. For an init syste…
Who else would have run a PostgreSQL performance benchmark and discover a major security issue in the process?
Earlier quoted context omitted.
Security Researchers : Is this request-for-private-disclosure + "90-days before public" reasonable? It's a SEVERE issue, to my mind, and 90 days seems too long to me.
Whether its reasonable is debatable, but that type of time frame is pretty normal for things that aren't being actively exploited. This situation is perhaps a little different as its not an accidental bug waiting to be discovered but an intentionally placed exploit. We know that a malicious person already knows about it.
Earlier quoted context omitted.
So many malicious actors have been caught because they accidentally created a mild annoyance for someone that went on to bird-dog the problem.
Which is why a really good backdoor is a one line logic bug somewhere which is fiendishly difficult to trigger.
Fascinating. Just yesterday the author added a `SECURITY.md` file to the `xz-java` project. > If you discover a security vulnerability in this project please report it privately. *Do not disclose it as a public issue.* This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released. Reading that in a different light, it says giv…
Security Researchers : Is this request-for-private-disclosure + "90-days before public" reasonable? It's a SEVERE issue, to my mind, and 90 days seems too long to me.
If it's a large company, made of people with names and faces, with a lot to lose by hacking its users, they're unlikely to abuse private disclosure. If it's some tiny library, the maintainers might be in on it.
Also, if there's evidence of exploitation in the wild, the embargo is a gift to the attacker. The existence of a vulnerability in that case should be announced, even if the specifics have to be kept under embargo.