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
