I think the #xz incident is teaching us that our infrastructure is dangerously fragile in the face of well-organized/funded attackers. The response isn’t “try harder” or “donate to your OSS project”, it needs to be institutional, professional, and at scale.
So, here’s my proposal, called “OSQI”, aimed at starting a how-to discussion: tbray.org/ongoing/When/202x/20…
reshared this
daniel:// stenberg://
in reply to Tim Bray • • •I think this has little chance of actually improving the world. A large org moving its weight around and assigning people to participate in projects who are not driven by the tech or a desire to use or improve the project?
I'm a skeptic.I'm afraid people will not come with the proper motivations and drive.
Jan Wildeboer 😷
in reply to daniel:// stenberg:// • • •Watching several foundations and organisations that had/have similar approaches since Heartbleed tells me that they often end up in bureaucracy and infighting, unfortunately.
UPDATE: In honouring the original request for a HOWTO discussion, that's my main point. Make very sure that (managerial) overhead is minimised to mostly admin stuff like paying bills and procurement. Avoid having charismatic "Heroes" that will try to put ego above goals.
daniel:// stenberg://
in reply to Jan Wildeboer 😷 • • •@jwildeboer indeed. Imagine also the imbalance in projects with a bunch of eager volunteers working their butts of in their spare time, only to have big-org assign a new person coming in from the outside - getting paid to be there - arguing for less features, slowing down and rather just doing more tests. Why would projects even listen to or care about them?
I understand the desire and intent but I think it is difficult to drive this from the outside like this.
Joe Cooper 🇺🇦 🍉
in reply to daniel:// stenberg:// • • •Bernd Paysan R.I.P Natenom 🕯️
in reply to daniel:// stenberg:// • • •@bagder @jwildeboer The difference for e.g. the NSA to get a small and a big-corp project backdoored is that for the first, they need a lot of social engineering, while for the latter, they'd just need to send an NSL. Or get one of theirs through the hiring process. And often, you can't tell the difference.
Eric Rescorla from Mozilla, who helped the Dual EC DRBG backdoor to get into the TLS RFCs is one of those persons I don't know on which side they are.
Aleksandra Fedorova
in reply to daniel:// stenberg:// • • •@bagder
Doing more tests doesn't sound like a bad thing though.
I wonder if the path of a third-party sponsored effort driving testing could actually be a good answer, which would free some community development resources to do feature development.
We would need to carve a role in the project carefully, so that it contributes without taking over, but it can be helpful.
@jwildeboer @timbray
Thomas Depierre
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Thomas Depierre • • •@Di4na we've done build systems for 40 years and we still cannot agree. Now we think we can make one to rule them all *by committee*?
Sure. /s
Thomas Depierre
in reply to daniel:// stenberg:// • • •@bagder ahah i would argue we have *not* done build systems for 40 years ;)
Just like we have not done programming languages adapted to this level for decades until we got lucky to steal some of Mozilla money. (I am not saying RiiR here)
daniel:// stenberg://
in reply to Thomas Depierre • • •@Di4na For the last 25 years, I have had people coming to my projects arguing for adding build system support for system X or rewriting it to only use system Z because the system Y is so bad.
The names and people change over time. But they still come.
Thomas Depierre
in reply to daniel:// stenberg:// • • •@bagder oh they do. That does not mean said systems were made and designed based on your needs.
We have a tendency in software, especially tools for devs, to build for our own imaginary world more than for what maintainers actually deal with...
daniel:// stenberg://
in reply to daniel:// stenberg:// • • •Thomas Depierre
in reply to daniel:// stenberg:// • • •@bagder oh i agree with you here. That is part of the problem. We did not even sit down to look at what happens and what are the problems people face.
We just. Shout out stuff we believe.
There is a reason i wrote to observe, listen and shut up in my blog yesterday :D
Thomas Depierre
in reply to Thomas Depierre • • •@bagder
I still do think we have a tooling problem, especially build systems. It takes a large amount of maintenance time out of the hobbyists maintainers limited ressources.
Does that means I am selling a solution? Nope. I do not have a good one rn. I have some ideas that could be explored, but that is far from being something to switch toward
What I think is worth considering is how we would fund exploring this problem.
Basically an older post of mine
softwaremaxims.com/blog/proces…
We Need More Process Engineering in Software
Thomas DepierreThomas Depierre
in reply to Thomas Depierre • • •@bagder because while Autoconf is not THE problem, I think we both can agree that Autoconf and Make are A problem in term of maintenance and experience for the person using them, at every level.
Does not mean we have something far better today. But it is something painful and ... Problematic. No?
daniel:// stenberg://
in reply to Thomas Depierre • • •it's like saying we have a problem with cars because their engines are too complicated and we should have simpler ones.
Sure maybe, but they are complicated for reasons.
I maintain that people have worked on and still are working on build systems for decades. If we need improvements there, then... well, someone should join those projects or start new build tool projects. I will not.
Thomas Depierre
in reply to daniel:// stenberg:// • • •@bagder I mean autoconf had no maintainers and releases for 8 years soooooo
And on car engine: i did not ask for less complexity ;)
daniel:// stenberg://
in reply to Thomas Depierre • • •@Di4na of course autconf is not ideal and it is fact rather quirky and hard to use.
That's why people did cmake, mason, blaze, scons, ninja and all those other alternatives.
I will not deny that we can improve. Everything can improve.
I'm not sure doing new build tools is a particularly big part of clamping down future xz attacks.
Thomas Depierre
in reply to daniel:// stenberg:// • • •@bagder oh i am not targeting xz attacks. I am targeting making life easier for maintainers.
I learned a long time ago to not focus on the latest attack. I use it as a Trojan horse to get stuff done.
Tim Bray
in reply to daniel:// stenberg:// • • •Troed Sångberg
in reply to daniel:// stenberg:// • • •@bagder
Even if I (let's say) would currently have an interest in maintaining project X and it would be possible to motivate to my employer, I will likely work on something else in 1-2 years time.
Not sure what that would do for long term stability.
@timbray
Tim Bray
in reply to daniel:// stenberg:// • • •@bagder To be fair, curl is obviously the kind of project that doesn't need the kind of help I'm suggesting. I specifically mentioned “Open-Source projects that have a high ratio of adoption to support”. Obviously OSQI would never have the resources to help with everything.
I actually don't know, are there more projects like curl or like xz? (There are plenty like xz.)
daniel:// stenberg://
in reply to Tim Bray • • •1. I did not say nor imply that I need that kind of help in curl 2. I am a maintainer of other well-used libraries as well (c-ares and libssh2), with much less contributors. I would maybe say they are closer to xz than curl.
curl has been in "the xz territory" during long times in its lifetime. I based my comments on my lifetime as an Open Source maintainer contributor.
But I also understand that being a critic is easy and I've said my piece now so I'll drop it now.
Tim Bray
in reply to daniel:// stenberg:// • • •