[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: chromium disabling use of shared libs, BoringSSL



On 2016-02-09 18:27, Jonas Smedegaard wrote:
Quoting Daniel Pocock (2016-02-09 17:47:46)
https://wiki.debian.org/EmbeddedCodeCopies mentions the following:
libevent ffmpeg glew webkit icu expat unicode-data minizip libxml2
protobuf libv8 nspr yasm libxslt sqlite3 snappy srtp tlslite

Seems not all of above are still true, however: Package in Sid links
against system shared ffmpeg and srtp, at least.

Has anybody else come across these situations with Chromium or Google
developers or other projects using BoringSSL?
Will the security team be happy to continue supporting the package?
I would hope they are not happy about current situation either...

Chromium upstream is tracking everything they ship pretty closely, especially OpenSSL, which they have forked in an embedded copy kind of way. They cleaned it up and do not want to be tied by API/ABI backwards compatibility in their attempts (well, mostly Adam Langley's) to make it more sane. You can't have multiple versions of BoringSSL in the same binary, nor can you link against OpenSSL. On the other hand Chromium then ends up in the weird position where you always need to update it in full rather than taking selected patches. And in reality that's how the security updates work, even in Debian.

Browsers are their own ecosystem. They deeply care about their TLS not being tampered with. Also Chromium really tries to be secure, using all the sandboxing that they can get to work.

If you'd split out BoringSSL, you'd ship it mainly for Chromium and would need to update it in lockstep with every release. I don't think there's a significant benefit to that. It does increase the complexity of updates as well.

Kind regards
Philipp Kern


Reply to: