|
|
|
|
|
by rurcliped
1786 days ago
|
|
The paper says "all three of OpenSSL, LibreSSL, and BoringSSL have been gradually increasing in size since the 2014 fork, to the point where LibreSSL is now roughly the same size as OpenSSL was at Heartbleed's discovery." The authors then count CVEs. This won't yield a valid conclusion about vulnerabilities in the new code that's been added to Libre/Boring in 2014-2021. The OpenSSL project requires use of CVE numbers, but Libre/Boring don't. Nothing at https://www.libressl.org or https://boringssl.googlesource.com/boringssl talks about obtaining or listing CVEs (contrast to https://www.openssl.org/news/vulnerabilities.html https://www.openssl.org/policies/secpolicy.html etc,). OpenSSL Management Committee has a person on CVE's board https://www.openssl.org/community/omc.html https://cve.mitre.org/community/board (same Mark Cox). The authors say "the most widely used cryptographic library, OpenSSL" but don't say this means more users to report bugs/vulnerabilities to that project. They say "Our case study of the LibreSSL and BoringSSL forks further demonstrates a linear correspondence between source code removal and vulnerability removal." Possibly a useful finding! But we still don't know what happens when you remove a ton of someone else's code, but then add a ton of your own unique code. To research that, they'd need competing projects that similarly care about vulnerability IDs (CVEs or other IDs), and have similar populations of potential bug reporters and/or similar opportunities for bug bounties. |
|