Hey folks! Many of us, probably almost everyone by now, have been following the XZ Utils situation. There have been many takes on how this was possible at all, both from the technical and the...
Hey folks!
Many of us, probably almost everyone by now, have been following the XZ Utils situation.
There have been many takes on how this was possible at all, both from the technical and the community point of view. The most security conscious have been overtaken by a sense of unease, especially as the most obvious question is posed: "how many times has this happened?".
This level of paranoia is certainly warranted, it always was as some are coming to realize, but I would like us all to remind people that systems are not only valuable due to their inherent robustness. Systems and software are also valuable, robust as well as secure due to the checks and balances within the processes that create them and act as fail-safes when said robustness is compromised.
Some are looking for culpability in FOSS, but a point I feel we should echo louder is that although FOSS might have delivered on its weaknesses it also, and most importantly, delivered on its strengths.
FOSS did deliver on its strengths, but we were fortunate with this find. It boiled down to a 500ms regression in performance that someone decided to dig deeper into. That kind of regression would...
FOSS did deliver on its strengths, but we were fortunate with this find. It boiled down to a 500ms regression in performance that someone decided to dig deeper into. That kind of regression would not even create a task on my task list to look at, and I'm more security-conscious than most. I believe that it wouldn't register for most software developers/engineers, security-conscious or not.
As to what needs to happen to prevent this in the future? I'm torn between privacy and a kyc/kyd (know your developer) process for open source. On one hand I value anonymity for the internet but for critical infrastructure I believe there does either need to be a a way to vet software developers who contribute to a FOSS project that is already in use on 100's of system or an innovation in code reviews:/testing that make spotting issues like this easier.
Code reviews, while essential, are boring and I know every software developer has approved a PR at least once without reading every single line/charactoer displayed. I completely missed the period for the landlock issue three times before I read a hint because I tend to speed read even during leisure reading. I know I have skimmed over dependabot dependency updated at least once on a Thursday at 4:45 before walking out the door, and honestly there's no telling what's in the code I approved.
Honestly, this wouldn't solve the problem. It'd be actively harmful to some who cannot share their identity, would shut out those whose online identities do not match their legal documents for...
As to what needs to happen to prevent this in the future? I'm torn between privacy and a kyc/kyd (know your developer) process for open source. On one hand I value anonymity for the internet but for critical infrastructure I believe there does either need to be a a way to vet software developers who contribute to a FOSS project that is already in use on 100's of system or an innovation in code reviews:/testing that make spotting issues like this easier.
Honestly, this wouldn't solve the problem. It'd be actively harmful to some who cannot share their identity, would shut out those whose online identities do not match their legal documents for whatever reason (think transgender people in certain places for example), and also raises the question of who really adjudicates on the validity of "official ID". Would a fake ID such as those used by underaged students to purchase alcohol suffice? What about cases you're dealing with a nation state actor who can trivially issue legitimate IDs for bad actors?
All of this is without getting into the fact that there are legitimately good reasons a FOSS maintainer may want to remain anonymous. The burden must be on those consuming open source software that they aren't implicitly trusting an upstream maintainer for critical packages. I mostly agree with your points on code review and want to point to efforts like the crev project which try and make the implicit trust explicit based off social code review. This is hard to scale but I remain hopeful organizations will eventually throw their might at it as well...Another thing we ought to be doing is making our tech less complex so things like review are more tractable but I suspect that's basically impossible now...
Interesting initiative, thank you for sharing it! Why do you think so? I think there is certainly hope, the conversation around supply-chain resilience in tech as well as dependency creep is very...
I mostly agree with your points on code review and want to point to efforts like the crev project which try and make the implicit trust explicit based off social code review.
Interesting initiative, thank you for sharing it!
Another thing we ought to be doing is making our tech less complex so things like review are more tractable but I suspect that's basically impossible now
Why do you think so? I think there is certainly hope, the conversation around supply-chain resilience in tech as well as dependency creep is very much alive. That doesn't mean much, but there is will there's a way, I suppose.
I fully agree, I've started curating a list of my favorite initiatives whose aim is supporting OSS/FOSS. It seems like every once in a while such an event is necessary to keep us on our toes and...
It seems like every once in a while such an event is necessary to keep us on our toes and remember that we ought to provide a support system; be it through monetary, work or other contributions.
One can hope. I love being at the bleeding edge for my personal stuff, but I want my servers to be 'set it and forget it.' A database migration between major versions is ideally only undertaken...
Similarly, for long-time opponents of “move fast, break things” and similar attitudes, this particular event should make their position much more palatable to management and customers throughout the tech industry.
One can hope. I love being at the bleeding edge for my personal stuff, but I want my servers to be 'set it and forget it.' A database migration between major versions is ideally only undertaken once every few years.
LTS should be the default state for anything user-facing. Supporting more-recent stuff is a nice bonus, but should not come at the expense of supporting any current LTS releases.
Even this stance is becoming increasingly untenable, as it brings with it unnecessary risk general users are neither informed nor probably capable of assessing and much less mitigating.
I love being at the bleeding edge for my personal stuff
Even this stance is becoming increasingly untenable, as it brings with it unnecessary risk general users are neither informed nor probably capable of assessing and much less mitigating.
Oh yes, it's called 'bleeding' for a reason. Don't use it unless you don't mind cutting yourself a bit. But I'm a bit of a sadomasochist, so it works out.
Oh yes, it's called 'bleeding' for a reason. Don't use it unless you don't mind cutting yourself a bit.
But I'm a bit of a sadomasochist, so it works out.
Hey folks!
Many of us, probably almost everyone by now, have been following the
XZ Utilssituation.There have been many takes on how this was possible at all, both from the technical and the community point of view. The most security conscious have been overtaken by a sense of unease, especially as the most obvious question is posed: "how many times has this happened?".
This level of paranoia is certainly warranted, it always was as some are coming to realize, but I would like us all to remind people that systems are not only valuable due to their inherent robustness. Systems and software are also valuable, robust as well as secure due to the checks and balances within the processes that create them and act as fail-safes when said robustness is compromised.
Some are looking for culpability in FOSS, but a point I feel we should echo louder is that although FOSS might have delivered on its weaknesses it also, and most importantly, delivered on its strengths.
I'd be happy to hear your thoughts.
FOSS did deliver on its strengths, but we were fortunate with this find. It boiled down to a 500ms regression in performance that someone decided to dig deeper into. That kind of regression would not even create a task on my task list to look at, and I'm more security-conscious than most. I believe that it wouldn't register for most software developers/engineers, security-conscious or not.
As to what needs to happen to prevent this in the future? I'm torn between privacy and a kyc/kyd (know your developer) process for open source. On one hand I value anonymity for the internet but for critical infrastructure I believe there does either need to be a a way to vet software developers who contribute to a FOSS project that is already in use on 100's of system or an innovation in code reviews:/testing that make spotting issues like this easier.
Code reviews, while essential, are boring and I know every software developer has approved a PR at least once without reading every single line/charactoer displayed. I completely missed the period for the landlock issue three times before I read a hint because I tend to speed read even during leisure reading. I know I have skimmed over dependabot dependency updated at least once on a Thursday at 4:45 before walking out the door, and honestly there's no telling what's in the code I approved.
Honestly, this wouldn't solve the problem. It'd be actively harmful to some who cannot share their identity, would shut out those whose online identities do not match their legal documents for whatever reason (think transgender people in certain places for example), and also raises the question of who really adjudicates on the validity of "official ID". Would a fake ID such as those used by underaged students to purchase alcohol suffice? What about cases you're dealing with a nation state actor who can trivially issue legitimate IDs for bad actors?
All of this is without getting into the fact that there are legitimately good reasons a FOSS maintainer may want to remain anonymous. The burden must be on those consuming open source software that they aren't implicitly trusting an upstream maintainer for critical packages. I mostly agree with your points on code review and want to point to efforts like the crev project which try and make the implicit trust explicit based off social code review. This is hard to scale but I remain hopeful organizations will eventually throw their might at it as well...Another thing we ought to be doing is making our tech less complex so things like review are more tractable but I suspect that's basically impossible now...
Interesting initiative, thank you for sharing it!
Why do you think so? I think there is certainly hope, the conversation around supply-chain resilience in tech as well as dependency creep is very much alive. That doesn't mean much, but there is will there's a way, I suppose.
I think reflecting on how we can support our package maintainers mentally and financially is pretty important too right now.
I fully agree, I've started curating a list of my favorite initiatives whose aim is supporting OSS/FOSS.
It seems like every once in a while such an event is necessary to keep us on our toes and remember that we ought to provide a support system; be it through monetary, work or other contributions.
Just a heads up, your link goes to localhost (did you mean this list?).
Interesting, I had fixed it!
Thanks for the heads up, edited and resubmitted. It looks correct now.
Yes, that's the one.
One can hope. I love being at the bleeding edge for my personal stuff, but I want my servers to be 'set it and forget it.' A database migration between major versions is ideally only undertaken once every few years.
LTS should be the default state for anything user-facing. Supporting more-recent stuff is a nice bonus, but should not come at the expense of supporting any current LTS releases.
Even this stance is becoming increasingly untenable, as it brings with it unnecessary risk general users are neither informed nor probably capable of assessing and much less mitigating.
Oh yes, it's called 'bleeding' for a reason. Don't use it unless you don't mind cutting yourself a bit.
But I'm a bit of a sadomasochist, so it works out.