> This experience makes me wonder how patches for the -security suites (default for unattended-upgrades) are tested and QA'ed. Can anything be done to the Ubuntu process to prevent things like this happening again?
For OpenSSL, we run it through a test suite and also test it with commonly run software such as Apache, Wget, etc. In this instance, the issue was an off-by-one which means it only affected certain certificates, and unfortunately not the certs that were used in our test suite. We've now added a test to parse all certs in the ca-certificates.crt file so this particular issue doesn't happen again.
> This experience makes me wonder how patches for the -security suites (default for unattended- upgrades) are tested and QA'ed. Can anything be done to the Ubuntu process to prevent things like this happening again?
For OpenSSL, we run it through a test suite and also test it with commonly run software such as Apache, Wget, etc. In this instance, the issue was an off-by-one which means it only affected certain certificates, and unfortunately not the certs that were used in our test suite. We've now added a test to parse all certs in the ca-certificates.crt file so this particular issue doesn't happen again.
> Debian seems to have got this one right in the first shot (DSA is here https:/ /www.debian. org/security/ 2016/dsa- 3673).
Debian hit the very same regression. See https:/ /lists. debian. org/debian- security- announce/ 2016/msg00255. html
> BTW: the links to upstream patches on the Ubuntu CVE page (http:// people. canonical. com/~ubuntu- security/ cve/2016/ CVE-2016- 2182.html) are invalid caused by a version string being appended to the commit hash
Thanks, I'll get that fixed.