3 ms·
In theory, the vulnerability was always there, and it's better to find out than not find out. In practice, how much effort it is to find vulnerabilities matter
by salsakran 5mo ago
In theory, the vulnerability was always there, and it's better to find out than not find out.
In practice, how much effort it is to find vulnerabilities matters a lot. We're in a time where things that used to be quite hard are now easy and the rate of discovery will change.
This rate of discovery matters a lot -- for OSS maintainer burnout if nothing else.
- tptacek 5mo agoIt matters in a positive sense; it's a thing that enables you to make some predictions about the state of the world tomorrow. It does not matter in a normative sense; OSS maintainer burnout is strictly a less important concern than software security, which is an externality of software development.
- Arainach 5mo ago> OSS maintainer burnout is strictly a less important concern than software security, Burnout means that no more fixes come - ever - and that things sit vulnerable until everyone relying on that tool takes the time to build and switch to a replacement. Maintainer burnout is perhaps the single biggest threat to the ecosystem right now.
- tptacek 5mo agoThat can't possibly be an argument for forbearing security vulnerabilities in software. It's an argument for prioritizing hypothetical flaws over real ones.
- Arainach 5mo agoIf these flaws are so important, users of open source (business or individual) need to pay up - literally. Pay the maintainers enough to justify spending the time on these things, including the opportunity cost of not working at other software jobs during that time. Pay each maintainer an absolute minimum of $200K a year or shut up and do the work yourself - in a fork if necessary.
- chadgpt3 5mo agoThis comment should not be greyed out. I feel that we all forget this far too much. You've exaggerated it somewhat. There is no right to demand someone does something for free, and we have gotten dependent on people doing things for free. We don't have to pay people but if we don't want to, then we have to be willing to do it ourselves. Otherwise it could go away at any moment and we have no recourse.
- salsakran 5mo agoStated differently -- the way OSS software is currently maintained and users are conditioned to behave, there is a capacity problem if the rate of discovery surges too sharply. And if the capacity is overshot (which I believe is happening as we speak), users end up in extended states of being insecure. I'm also one of the unwashed rabble who believes there is a large practical difference between a vulnerability that exists but isn't found and one that is widely known and exploitable.
- tptacek 5mo agoThere's two fallacious arguments encoded here. The first is obvious, that we should prioritize hypothetical future vulnerabilities and fixes over ones we know exist today. The second is subtler and more insidious: it's the idea that the goal of software is to ensure every package and project is viable, that everyone who wants to deploy it should be able to do so. The risks this attitude pose to users, ordinary people who have no agency over which software packages you use to serve their needs, are a pure externality. The idea that a project serving real human users might opt to compromise availability rather than putting people at risk is never even broached.
- 48terry 5mo agoIf the maintainers burn out, nobody's going to be making your software secure.
- tptacek 5mo agoThen people will stop using that software.
- 48terry 5mo agoThis is so far outside of reality that I can't believe I'm even commenting on it. If you believe people don't use software that is unmaintained and hilariously out of date I genuinely don't know what world you live in or how to deliver the bad news to you.
- tptacek 5mo agoOh, I agree that today there's a general expectation that externalized security doesn't matter and someone will always come around to rescue you (and your unmaintained dependency) from disaster. I'm just saying: infinite free bugs is likely to disrupt that equilibrium.