Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
xz-mirror
Mirror of Tukaani's XZ codebase including the ssh backdoor (https://www.openwall.com/lists/oss-security/2024/03/29/4)
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
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, and the patches enabling the backdoor merged a few days later. It could be a total coincidence or it could be that the attacker was trying to catch the window before it was closed on them https://github.com/systemd/systemd/pull/31550#issuecomment-1...
The points you make aren't unreasonable.
It is necessary to establish clear boundaries of what can and can be provided by the maintainers. If not done at an earlier stage of the project, the support burden becomes too much to bear at which point the maintainer transfers ownership, and the project suffers from catastrophic consequences such as the xz backdoor we're talking about here, or other cases where the project mostly stalls and serves as an ego-boosting platform for the new maintainer, as was the case with PhantomJS[6].
This can also happen in your life, where a "friend" sees that you possess a certain skill, and then gradually tries to push an inordinate amount of their personal work related to this field onto you.
Personally, I think it's best to use an approach with extremely clear communication as to what the maintainer can and cannot provide. This can be seen, for example, in yt-dlp[1], where the consumer is clearly informed upfront that not providing detailed information as requested will lead them to block said consumer; or sqlite where their position regarding contributed patches[2] and support[3] is similarly made clear.
Having a shouty BDFL like Torvalds can also help improve code quality[4] and questionable contributions[5], though it is better that the shouty BDFL makes statements that are professional and do not show as much aggression; so for example, "Mauro, shut the fuck up"[7] would become "Mauro, your response is completely unbecoming for a Linux kernel maintainer, and is not in line with the promise of not breaking userspace."
[1] https://github.com/yt-dlp/yt-dlp/issues/new?assignees=&label...
[2] https://www.sqlite.org/copyright.html
[3] https://www.sqlite.org/support.html
[4] https://www.theregister.com/2024/01/29/linux_6_8_rc2/
[5] https://cse.umn.edu/cs/linux-incident
[6] https://github.com/ariya/phantomjs/issues/14541
[7] https://lkml.org/lkml/2012/12/23/75
The points you make aren't unreasonable.
It is necessary to establish clear boundaries of what can and can be provided by the maintainers. If not done at an earlier stage of the project, the support burden becomes too much to bear at which point the maintainer transfers ownership, and the project suffers from catastrophic consequences such as the xz backdoor we're talking about here, or other cases where the project mostly stalls and serves as an ego-boosting platform for the new maintainer, as was the case with PhantomJS[6].
This can also happen in your life, where a "friend" sees that you possess a certain skill, and then gradually tries to push an inordinate amount of their personal work related to this field onto you.
Personally, I think it's best to use an approach with extremely clear communication as to what the maintainer can and cannot provide. This can be seen, for example, in yt-dlp[1], where the consumer is clearly informed upfront that not providing detailed information as requested will lead them to block said consumer; or sqlite where their position regarding contributed patches[2] and support[3] is similarly made clear.
Having a shouty BDFL like Torvalds can also help improve code quality[4] and questionable contributions[5], though it is better that the shouty BDFL makes statements that are professional and do not show as much aggression; so for example, "Mauro, shut the fuck up"[7] would become "Mauro, your response is completely unbecoming for a Linux kernel maintainer, and is not in line with the promise of not breaking userspace."
[1] https://github.com/yt-dlp/yt-dlp/issues/new?assignees=&label...
[2] https://www.sqlite.org/copyright.html
[3] https://www.sqlite.org/support.html
[4] https://www.theregister.com/2024/01/29/linux_6_8_rc2/
[5] https://cse.umn.edu/cs/linux-incident
[6] https://github.com/ariya/phantomjs/issues/14541
[7] https://lkml.org/lkml/2012/12/23/75
A mirror is here[1] for someone who wants to read the commit messages, though as I understand it is insufficient for reproducing the backdoor at compile time because it is missing the m4/ files required for this purpose.
[1] https://github.com/supriyo-biswas/xz-mirror
I do not use or recommend security through obscurity.
Such things can always be automatically discovered.
https://github.com/eliemoutran/KnockIt
Any effort spent on setups like this is likely better spent removing the need for having ssh at all by moving to lean appliance unikernel setups where servers are maintained by API like TalosOS or similar.
Be direct and put the onus on the reporter/contributor to do more work before you will engage.
e.g., here is Daniel Lemire responding to a very open-ended bug report: https://github.com/lemire/streamvbyte/issues/72
There is something similar in customer service for my SaaS. Customers give horribly vague bug reports. I used to try to divine what they wanted. That way leads burnout. Instead, make them do more of the work.
One example of a useful technique
https://serenityos.org/ apparently only makes source code available. There are no binary images of the OS to install
I think Andreas said this functions like a little test -- if you're not willing to build it from source, then you probably wouldn't be a good contributor anyway.
---
Likewise, my shell project provides source tarballs only, right now - https://www.oilshell.org/release/0.21.0/
It is packaged in a number of places, which I appreciate. That means some other people are willing to do some work.
And they provide good feedback.
I would like it to be more widely available, but yeah I definitely see that you need to "gate" peanut gallery feedback a bit, because it takes up a lot of time.
Of course, it's a tricky balance, because you also want feedback from casual users, to make the project better.