blog

libre-software-security-disclosure.xml (3910B)

<entry>
<title>Security Disclosures for Libre Software</title>
<link rel="alternate" type="text/html" href="/articles/libre-software-security-disclosure"/>
<id>https://hacktivis.me/articles/libre-software-security-disclosure</id>
<published>2024-02-26T05:44:04Z</published>
<updated>2024-02-26T05:44:04Z</updated>
<link rel="external replies" type="application/activity+json" href="https://queer.hacktivis.me/objects/8a91bd0c-a782-43dd-9c2f-0ef1bdc5025b" />
<link rel="external replies" type="text/html" href="https://queer.hacktivis.me/objects/8a91bd0c-a782-43dd-9c2f-0ef1bdc5025b" />
<content type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" class="h-entry">
<p>
	A common way security disclosures are done -specially in the proprietary world- is to only give a heads-up notification to your licensees or maybe even a specific sub-group of them (yikes), and to continue doing so until the last moment. This mindset also means keeping the notifications confidential, possibly with encryption, because if it would ever leak you'd end up creating a <a href="https://en.wikipedia.org/wiki/0day">0day</a> against your software.<br />
	To me this is playing with fire but not only.
</p>
<p>
	Because it fundamentally cannot work correctly with public licensing where by very definition anyone is a licensee, you could try to notify distribution maintainers ahead, but your list still isn't going to be exhaustive. And good luck trying to have a confidential channel to hundreds of very different people/organisations. ("I want to use GnuPG to contact all distros" isn't a hill, it's a cliff, don't walk towards it.)<br />
	This is why I think the best is to also gradually disclose information in the open, you can still notify distribution maintainers, but don't make it an in-group. For example if writing a patch takes time, you can publish a workaround ("A vulnerability in feature $X got reported, disable it"). It also means that when publishing the patch, you <em>do not</em> describe what vulnerability it fixes, make it more like a mere bug and link it to an identifier (CVE, bug-id, …).
</p>
<p>
	That said similarly to <a href="https://en.wikipedia.org/wiki/Full_disclosure_(computer_security)">full disclosure</a> I think information about flaws should be published in full, if only to benefit other researchers and implementers. But I think it should be done after a deadline (of say a month) rather than right away so everyone has the time to apply the fixes, forks included. As well as possibly independant implementations finding similar flaws.
</p>
<p>
	By the way this is one of the many reasons why I like network-copyleft licenses for networking software like the <a href="https://en.wikipedia.org/wiki/EUPL">EUPL</a> and the <a href="https://en.wikipedia.org/wiki/GNU_Affero_General_Public_License">AGPL</a>. They forces to throw away the proprietary mindset, where if you need to deploy a security fix in production, you make it available for everyone. Otherwise you're effectivelly choosing to keep the security of everyone else weaker, which in a network means everyone, typically you included.
</p>
<p>
	Also I think coordination is entirely broken, even if you'd somehow magically fix the in-group/out-group problem and the time taken for the coordination of the planet-alignment that is publishing at the same time. It relies on the found-wrong assumption that the report you received is from the first discoverer <em>and</em> that no one else will discover it in your painfully long coordination timeline.<br />
	Finding flaws because they're being actively exploited isn't rare. And given there's both corporations and governments actively researching for exclusive vulnerabilities to keep for themselves: We should consider that when a flaw is reported, it might be already known. (Or let's be honest, trivial to find)
</p>
</div>
</content>
</entry>