How quickly should you fix vulnerabilities?
As quickly as possible, right? Maybe not. In a well-reasoned post on the PivotNine blog, Justin Warren wrote:
I would encourage more unsupported maintainers to do just that. Stop rushing to fix bugs for people without a support contract. Patch security flaws at a more leisurely pace unless someone is willing to pay for greater urgency. Take your time and enjoy your hobby more, since that is what unpaid software maintenance is. … Businesses and governments need to get used to the idea that you are not part of their “software supply chain” unless they are a paying customer.
This is part of the broader “I am not a supplier” sentiment that has built in the last few years. I am sympathetic to this position. Open source software is, after all, almost always provided as-is with no guarantees of quality or fitness for purpose. The only obligations on maintainers are the ones they choose to accept for themselves.
I am generally all for maintainers choosing the “fuck you, pay me” route if that’s what they want. At the same time, it feels like a bad approach to addressing vulnerabilities. Security flaws don’t just affect the big companies who should invest in their upstreams more than they do (on average). They also affect the users of the big company software, as well as other hobbyists and random users.
These vulnerabilities can have significant impact on the finances, data, and privacy of real people. To know about a vulnerability and choose to let it sit until someone comes along with money feels anti-social to me. Whether hobbyist or professional, developers try to write good code. It’s reasonable to not hold hobbyists (even if they’re professionals during the workday) to a high standard. But the social contract that no one has ever explicitly stated says that we should try not to write vulnerabilities and that we should make a good-faith effort to fix them when they’re raised.
Warren seems to advocate breaking this social contract, since no one agreed to it in the first place. The idea that parties must knowingly accept the terms of a contract is a pretty foundational pillar of contract law. Social contracts, of course, are not legally binding, but the implication is there.
And this brings me to my slight disagreement with what Warren wrote. The wrong time to say you’re not going to be fixing a vulnerability without a support contract is when someone submits the report. The right time is in your README or other project documentation, right up front. This — in theory, although there will always be people who won’t see it — gives people the information they need to make an informed decision about whether or not your project is appropriate for their use. People will assume you’ll try to fix vulnerabilities quickly, unless you clearly set an expectation otherwise.