Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team?
The Android SDK is really probably more like Eclipse. About 5 years of
support, they are still maintaining Android 2.3.3 to some degree and
that's at least 5 years old.
https://android.stackexchange.com/a/84816
Also, the security profile is relatively low risk for the Android SDK in
general:
* mostly various user utilities
* no setuid or special permissions
* only one daemon-like thing, adb, with no net access by default
* a good chunk is just files on the filesystem (e.g. libs for Android apps)
.hc
Hans-Christoph Steiner:
>
> 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: