Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team?
BoringSSL is just a part of the Android SDK. It has an unstable API
because it is only the C backing to a single Java library called
conscrypt. That library is in turn only used as part of the Android
SDK. Using the upstream build system, all of the source code is checked
out at once from many git repos, and built together. Compare this to
Firefox, OpenJDK, gcc, or any large project: there are lots of chunks of
source code that are organized internally as "libraries".
We are packaging these chunks separately because we believe it will make
it easier to maintain. Security updates can happen only in the
particular package rather than having to build the whole Android SDK
together as one giant source tree.
Upstream is already good at providing security fixes for all of the
various bits, and they maintain quite a few stable releases in parallel.
Security maintenance for the Android SDK packages will mostly be a
matter of just including any new patch versions (i.e. 6.0.1_r14 vs
6.0.1_r15).
.hc
Ralph Sanchez:
> My opinion might not mean much, but as a user, I agree with this. If
> i'm installing from the stable depository, we expect certain things
> from packages there and everything must be held to those guidelines.
> And mostly if we are using it from unstable, we are hoping to see it
> evolve into being put into the stable form, not just stagnate or we
> won't use it, which is bad for the both the user (losing out on
> promising programs) and the company (losing out on users), i think
>
> On Tue, May 17, 2016 at 11:27 AM, Michael Stone <mstone@debian.org> wrote:
>> On Tue, May 17, 2016 at 04:02:37PM +0800, seamlikok@gmail.com wrote:
>>>
>>> BoringSSL is also free software, as long as there are maintainers who
>>> are willing to spend time on it, I think it has rights to exist in
>>> Debian. Well I have been contributing to Debian for not long, so
>>> please point me out my mistakes. :)
>>
>>
>> The question is, "who does the security updates for the package 5 years from
>> now". As a general rule, we don't allow private embedded copies of libraries
>> because then a security update for a library means chasing down and fixing
>> any number of copies. (In historic terms, this was a huge issue, for
>> example, with zlib bugs.) On top of that, if the upstream says flat-out that
>> it's an unstable API, putting it into a debian release seems like a bad
>> idea. Putting it unstable and never letting it make it to stable is a
>> possibility, but the point of unstable is to eventually get packages into a
>> released version so that seems somewhat an abuse of the system. If it's
>> really a standalone component that's expected to change a lot and not
>> interact with anything else in debian, then putting it in an external
>> repository seems like a better fit.
>>
>> Mike Stone
>>
>
Reply to: