Tootfinder

Do you know one (wo)man open source projects maintainer? Currently in my list: @… and @…

Do you know one (wo)man open source projects maintainer? Currently in my list: @… and @…

Florian Westphal stepped down as #Linux' #netfilter maintainer
"'"I do not feel that I'm up to the task anymore.
I hope this to be a temporary emergency measure, but for now I'm sure this is the best course of action for me."'"

As I knew I was on holiday for soft freeze I got all my #qemu maintainer PRs in early for 9.0. It is now released to the wild. The big #arm64 update is FEAT_NV2 emulation as well as a number of enhancements to various board models (and some deprecations of the older unloved code). For

SA development is so slow and trust-based that I can’t imagine us ever getting an ‘over the transom’ submission of LLM-generated code and paying any attention to it.
Rules are a different story, as those just need to prove themselves in QA. We've already got some rules that are algorithmically generated, but no one claims that to be “AI" and a trusted human does the commit before RuleQA gets to put them to the test.

#Verpasstodon
Einige der zuletzt hier besonders häufig geteilten #News:
xz-Attacke: Hinweise auf ähnliche Angriffsversuche bei drei JavaScript-Projekten

Florian Westphal stepped down as #Linux' #netfilter maintainer
"'"I do not feel that I'm up to the task anymore.
I hope this to be a temporary emergency measure, but for now I'm sure this is the best course of action for me."'"

holy hell Github - this is bad
heads up repo maintainers on Github - you may want to disable interactions for now
The last thing any OSS maintainer needs is their project getting a strike because some bad actor chose their repo 😤
https://infosec.exchange/@BleepingComp

This is a fascinating glimpse into the *beginning* of the #xz exploit, i.e. the social engineering.
Some users (accomplices of the attacker?) used the dev mailing list to badger and harass the maintainer of the project who was on the verge of burnout, to pressure him to grant co-maintainer status to the attacker.
Whether this was part of the attack or not, it’s a sad glimpse into the toxic pa…

#Verpasstodon
Einige der zuletzt hier besonders häufig geteilten #News:
xz-Attacke: Hinweise auf ähnliche Angriffsversuche bei drei JavaScript-Projekten

Shots fired by the flake8 maintainer.
We can have a nuanced discussion about the failures of flake8 etc, but you’ll still have to acknowledge that a VC-backed, non-Python project profited from decades of community work, & has sucked all air out of the space.
It’s not like I’m not using Ruff—but I do it begrudgingly & find the cheerleading around it baffling. It has practically destroyed a part of the ecosystem & it looks like nobody has seen the VC playbook play out.<…

This interview with Linus Torvalds on the qualities that maintainers need (in contrast to developers) and maintainer fatigue summarizes a few things I keep bringing up:
- maintenance is not "bugfixing" as a lesser/different kind of coding, it's about experience, about having done a lot of things to give context to what you are seeing and to have some understanding of what second order consequences a choice might have
- maintenance is about collaboration and cooperat…

It really triggers me when inactive #Gentoo developers claim that they're "active", they just don't have anything to do. It's just that the 5 semi-dead packages that they're maintaining don't need any work!
Let's get some numbers.
Right now, there are almost 2000 packages without maintainer in Gentoo. There is probably even more packages that are effectively unmaintained, i.e. assigned to a developer or a project that's not actually maintaining them.
There are over 2000 open bugs assigned to maintainer-needed@ (i.e. directly related to unmaintained packages). There are 78 more open security bugs where unmaintained packages are involved.
In total, there are around 24 thousand open bugs (that's without new package requests). A large number of them is literally waiting to be closed because they're already fixed or are no longer relevant (yes, we'd use some help sieving through the old bug reports).
Over the last 30 days, 7 top committers were responsible for 75% of commits to the Gentoo repository. 20 top committers account for 90% of the commits.
Consider all this, and once again tell me, with a straight face, that there's nothing for you to do. Tell me that it's fair that you are still a developer while barely doing anything at all, for over half a year, while 20 people do 90% of all the work (admittedly, commit numbers are not an exact measure of activity but these are easy numbers demonstrating the point). 20 people have done over 9000 commits over the last month, and you can't do one.
Helpful command to get statistics: git shortlog --since='30 days ago' -sn --group=committer

Been following the #MkDocs drama for some time. So sad to see a project with so much potential struggle so much. Hope a new maintainer is found soon https://github.com/mkdocs/mkdocs/discu

I am stepping down from MkDocs · mkdocs mkdocs · Discussion #3621
3 years ago I was given push access to MkDocs among a few other people, without a single word regarding how anything should be done. Even the ability to make a release hinged on a leftover API toke...

CDN-hosted JS has always smelled more than a little funny to me. It’s all the problems of a library supply chain attack, except that an attacker can hot swap the malicious into your already-deployed site. Maybe only for a brief time window. Maybe only for specific regions or specific users.
https://oisaur.com/@r…

The security of the worldwide information technology infrastructure sadly rests on tons of unpaid open source developers. 😦
https://www.theverge.com/2024/4/2/24119342/xz-utils-linux-backdoor-attempt

How one volunteer stopped a backdoor from exposing Linux systems worldwide
A maintainer for a Linux-based database identified malicious code hidden in a tool called XZ Utils and stopped a global security breach in its tracks.

I said I wasn't going to be a sole maintainer again .... but anyway: today I published the first packaged version of openapi-overlays-js in response to user requests. If you work with OpenAPI files that you need to update as part of your process, this is for you. https://www.npmjs.com/package/openapi-overlays-js

Don't you just love people submitting security vulnerabilities for versions which turn out to be 6 years old and have already been fixed 4 major versions ago? In the past few hours the same person (don't think it's a bot) submitted similar bogus issues to a handful of other projects, seemingly trying to bump up their GitHub contribs, but potentially going to waste other maintainer's time too... It took out 30 mins of my life taking this report seriously and trying to reproduc…

So we are working on the last stages of the Vivaldi 6.6 desktop release. We are up to release candidate two.
Anyway… I am asking for a little favour not as an employee but in my unofficial role as the Vivaldi flatpak maintainer. 😉
Is there anyone around with x64 Linux, right now? If so I am wondering if one of you can install this flatpak 6.6 RC2 test build and confirm that proprietary media works

mostly what I think I'd want if I were an opensource maintainer is an accountability buddy, a test user, and a mentor
I bet some of that you can get in like, groups of devs, if it's the same protocol.
like #fedidevs

"As some of the dust around the xz backdoor is slowly starting to settle, we’ve been getting a pretty clear picture of what, exactly, happened, and it’s not pretty... I’m suggesting the idea of setting up a foundation – or whatever legal entity makes sense – that is dedicated to helping maintainers who face the kinds of problems like the maintainer of xz did." Open source is about more than just code:

It would be great if every open source maintainer automatically had some way to accept donations and it was common practice to donate if you wanted something done (including vague “fix more bugs” or “maintenance”) instead of complaining.
From: @…

@… Your blurb is hysterical. Not left. I didn't consider myself left either though my positions on things were way more aligned with those of a left wing ideology than the right. Neither a hiker nor a trail maintainer but I cut and pull invasive vines

One thing I have yet to see much of in this #xz debacle is much if any empathy for the original project maintainer. From what I can gather they’ve been toiling away on this project for at least 2 decades, have faced mental health issues in that time that required them to take breaks from it, and that the alleged hacker potentially conned their way into a position of authority for the project.
I can…

Thoughts and prayers to the xz maintainer.
Because I don't really know what we should do

If your tech company has more than 100 employees you should be forced to have an open source maintainer on staff that's not connected to your business model/goals.

(You've got to hope it was a state sponsored attack, because nobody wants to think about a lone maintainer Tyler Durdening it up on their own.)

For anyone who has missed it: One of the maintainers of xz/liblzma (& libarchive?) has apparently been backdooring it for a couple of years. Fortunately it seems to only target Debian-based distros!? So once again I luck out with my oblivious computing choices, having almost everything personally and professionally either EL-based or BSD-based
#InfoSec

(You've got to hope it was a state sponsored attack, because nobody wants to think about a lone maintainer Tyler Durdening it up on their own.)

#Verpasstodon
Einige der zuletzt hier besonders häufig geteilten #News:
xz-Attacke: Hinweise auf ähnliche Angriffsversuche bei drei ##JavaScript-Projekten

okay, so the XZ backdoor.
none of the automated tools we're proposing to catch illegitimate artifacts would ever solve a malicious maintainer. how would you even "zero trust framework" that?
upstreams of upstreams of upstreams
even if you did unikernels and distroless or single binaries, like you're not going "I have to audit every package update ever made upstream of #chainguard" (because they certainly aren't code reviewing every patch with a team that size)
or every package included in a rust/cargo build.
or every patch to golang stdlib
how on earth would finding that kind of a "they became the maintainer and added the backdoor themselves" actually ever be feasible, as in not bankrupting you?
vs "we built it with stdlib only, and we monitor stdlib's patches, we have only one upstream" which feels like... no company ever
#xz #xzbackdoor #sbom #zerotrust

My current take on the #xz situation, not having read the actual source backdoor commits yet (thanks a lot #Github for hiding the evidence at this point...) besides reading what others have written about it (cf. #rustlang for such central library dependencies would maybe (really big maybe) have made it a bit harder to push a backdoor like this because - if and only if the safety features are used idiomatically in an open source project - reasonably looking code is (a bit?) more limited in the sneaky behavior it could include. We should still very much use those languages over C/C for infrastructure code because the much larger class of unintentional bugs is significantly mitigated, but I believe (without data to back it up) that even such "bugdoor" type changes will be harder to execute. However, given the sophistication in this case, it may not have helped at all. The attacker(s) have shown to be clever enough.
6. Sandboxing library code may have helped - as the attacker(s) explicitly disabled e.g. landlock, that might already have had some impact. We should create better tooling to make it much easier to link to infrastructure libraries in a sandboxed way (although that will have performance implications in many cases).
7. Automatic reproducible builds verification would have mitigated this particular vector of backdoor distribution, and the Debian team seems to be using the reproducibility advances of the last decade to verify/rebuild the build servers. We should build library and infrastructure code in a fully reproducible manner *and* automatically verify it, e.g. with added transparency logs for both source and binary artefacts. In general, it does however not prevent this kind of supply chain attack that directly targets source code at the "leaf" projects in Git commits.
8. Verifying the real-life identity of contributors to open source projects is hard and a difficult trade-off. Something similar to the #Debian #OpenPGP #web-of-trust would potentially have mitigated this style of attack somewhat, but with a different trade-off. We might have to think much harder about trust in individual accounts, and for some projects requiring a link to a real-world country-issued ID document may be the right balance (for others it wouldn't work). That is neither an easy nor a quick path, though. Also note that sophisticated nation state attackers will probably not have a problem procuring "good" fake IDs. It might still raise the bar, though.
9. What happened here seems clearly criminal - at least under my IANAL naive understanding of EU criminal law. There was clear intent to cause harm, and that makes the specific method less important. The legal system should also be able to help in mitigating supply chain attacks; not in preventing them, but in making them more costly if attackers can be tracked down (this is difficult in itself, see point 8) and face risk of punishment after the fact.
H/T @… @… @… @… @…

My current take on the #xz situation, not having read the actual source backdoor commits yet (thanks a lot #Github for hiding the evidence at this point...) besides reading what others have written about it (cf. #rustlang for such central library dependencies would maybe (really big maybe) have made it a bit harder to push a backdoor like this because - if and only if the safety features are used idiomatically in an open source project - reasonably looking code is (a bit?) more limited in the sneaky behavior it could include. We should still very much use those languages over C/C for infrastructure code because the much larger class of unintentional bugs is significantly mitigated, but I believe (without data to back it up) that even such "bugdoor" type changes will be harder to execute. However, given the sophistication in this case, it may not have helped at all. The attacker(s) have shown to be clever enough.
6. Sandboxing library code may have helped - as the attacker(s) explicitly disabled e.g. landlock, that might already have had some impact. We should create better tooling to make it much easier to link to infrastructure libraries in a sandboxed way (although that will have performance implications in many cases).
7. Automatic reproducible builds verification would have mitigated this particular vector of backdoor distribution, and the Debian team seems to be using the reproducibility advances of the last decade to verify/rebuild the build servers. We should build library and infrastructure code in a fully reproducible manner *and* automatically verify it, e.g. with added transparency logs for both source and binary artefacts. In general, it does however not prevent this kind of supply chain attack that directly targets source code at the "leaf" projects in Git commits.
8. Verifying the real-life identity of contributors to open source projects is hard and a difficult trade-off. Something similar to the #Debian #OpenPGP #web-of-trust would potentially have mitigated this style of attack somewhat, but with a different trade-off. We might have to think much harder about trust in individual accounts, and for some projects requiring a link to a real-world country-issued ID document may be the right balance (for others it wouldn't work). That is neither an easy nor a quick path, though. Also note that sophisticated nation state attackers will probably not have a problem procuring "good" fake IDs. It might still raise the bar, though.
9. What happened here seems clearly criminal - at least under my IANAL naive understanding of EU criminal law. There was clear intent to cause harm, and that makes the specific method less important. The legal system should also be able to help in mitigating supply chain attacks; not in preventing them, but in making them more costly if attackers can be tracked down (this is difficult in itself, see point 8) and face risk of punishment after the fact.
H/T @… @… @… @… @…