Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #4776 > unrolled thread

Will Packaging BoringSSL Bring Any Trouble to the Security Team?

Back to article view | Back to linux.debian.security

Contents

  Will Packaging BoringSSL Bring Any Trouble to the Security Team? 殷啟聰 <seamlikok@gmail.com> - 2016-05-13 07:50 +0200
    Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team? Moritz Mühlenhoff <jmm@inutil.org> - 2016-05-13 08:50 +0200
      Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team? Moritz Mühlenhoff <jmm@inutil.org> - 2016-05-13 21:10 +0200
      Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team? Elmar Stellnberger <estellnb@gmail.com> - 2016-05-13 22:40 +0200
        Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team? 殷啟聰 <seamlikok@gmail.com> - 2016-05-17 10:10 +0200
          Will Packaging BoringSSL Bring Any Good to Debian Geert Stappers <stappers@debian.org> - 2016-05-17 10:50 +0200
          Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team? Michael Stone <mstone@debian.org> - 2016-05-17 17:30 +0200
            Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team? Ralph Sanchez <rwsanchez3@gmail.com> - 2016-05-17 17:40 +0200
              Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team? Hans-Christoph Steiner <hans@at.or.at> - 2016-05-18 12:00 +0200
                Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team? Hans-Christoph Steiner <hans@at.or.at> - 2016-05-18 12:30 +0200

#4776 — Will Packaging BoringSSL Bring Any Trouble to the Security Team?

Dear Debian Security Team,

The "android-tools" packaging team
<https://qa.debian.org/developer.php?login=android-tools-devel%40lists.alioth.debian.org>
are introducing BoringSSL, a fork of OpenSSL by Google. The latest
Android OS and its SDK no longer use OpenSSL and they use some APIs
only provided by BoringSSL, hence we are bringing BoringSSL to Debian.
You can see the ITP at <https://bugs.debian.org/823933>.

All headers and libraries of BoringSSL are installed under private
directories, e.g. "/usr/lib/${DEB_HOST_MULTIARCH}/boringssl". Thus
BoringSSL's package won't conflict with OpenSSL's packages. Any
libraries wishing to use BoringSSL must set their RPATH accordingly.

Seems that OpenSSL is taken heavy care of by Debian's security team,
so I wonder if BoringSSL will bring you any trouble? If no one has
objections, we will upload this package soon.

Cheers,
Kai-Chung Yan

-- 
/*
* 殷啟聰 | Kai-Chung Yan
* 一生只向真理與妻子低頭
* Undergraduate student in National Taichung University of Education
* LinkedIn: <https://linkedin.com/in/seamlik>
* Blog: <http://seamlik.logdown.com>
*/

[toc] | [next] | [standalone]

#4777

殷啟聰 <seamlikok@gmail.com> schrieb:
> Dear Debian Security Team,

Our contact address is team@security.debian.org, not debian-security...

> The "android-tools" packaging team
><https://qa.debian.org/developer.php?login=android-tools-devel%40lists.alioth.debian.org>
> are introducing BoringSSL, a fork of OpenSSL by Google. The latest
> Android OS and its SDK no longer use OpenSSL and they use some APIs
> only provided by BoringSSL, hence we are bringing BoringSSL to Debian.
> You can see the ITP at <https://bugs.debian.org/823933>.

No, that's not acceptable. You can try to provide that additional APIs
on top of OpenSSL, but we're not going to support an entire OpenSSL
fork just for Google's NIH syndrome.

Cheers,
        Moritz

[toc] | [prev] | [next] | [standalone]

#4779

Moritz Mühlenhoff <jmm@inutil.org> wrote:
>> are introducing BoringSSL, a fork of OpenSSL by Google. The latest
>> Android OS and its SDK no longer use OpenSSL and they use some APIs
>> only provided by BoringSSL, hence we are bringing BoringSSL to Debian.
>> You can see the ITP at <https://bugs.debian.org/823933>.
>
> No, that's not acceptable. You can try to provide that additional APIs
> on top of OpenSSL, but we're not going to support an entire OpenSSL
> fork just for Google's NIH syndrome.

Even upstream advises against that, BTW:
Quoting from https://boringssl.googlesource.com/boringssl/:

| BoringSSL is a fork of OpenSSL that is designed to meet Google’s needs.
| Although BoringSSL is an open source project, it is not intended for general
| use, as OpenSSL is. We don’t recommend that third parties depend upon it.
| Doing so is likely to be frustrating because there are no guarantees of
| API or ABI stability.

Alternatively you could only keep it in unstable (by blocking it from
transitioning to testing with an RC bug), but that would of course keep
the Android SDK limited to sid as well (which might be acceptable given
that it's for development on a rather fast-moving target anyway).

Cheers,
        Moritz

[toc] | [prev] | [next] | [standalone]

#4780

   Just wanted to tell that I am quite happy not to have boringSSL in 
Debian - main. I think it is depeerable there apart from the security 
risk of adopting the SSL package from a company which was largely funded 
by intelligence services and the Pentagon. I would rather like to see 
OpenBSD`s libressl as an option for Debian. I believe the OpenBSD 
programmers have done a pretty good job at it!

Elmar

Am 2016-05-13 um 08:44 schrieb Moritz Mühlenhoff:
> 殷啟聰 <seamlikok@gmail.com> schrieb:
>> Dear Debian Security Team,
>
> Our contact address is team@security.debian.org, not debian-security...
>
>> The "android-tools" packaging team
>> <https://qa.debian.org/developer.php?login=android-tools-devel%40lists.alioth.debian.org>
>> are introducing BoringSSL, a fork of OpenSSL by Google. The latest
>> Android OS and its SDK no longer use OpenSSL and they use some APIs
>> only provided by BoringSSL, hence we are bringing BoringSSL to Debian.
>> You can see the ITP at <https://bugs.debian.org/823933>.
>
> No, that's not acceptable. You can try to provide that additional APIs
> on top of OpenSSL, but we're not going to support an entire OpenSSL
> fork just for Google's NIH syndrome.
>
> Cheers,
>         Moritz
>

[toc] | [prev] | [next] | [standalone]

#4788

Hi all,

Sorry for posting to a general channel. I didn't know that :(

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. :)

I understand that the security team do not want to support it, but
what if you don't have to? This package places BoringSSL in a private
directory which is isolated to other libraries, and only Android SDK
is using the libraries. Hence all the other packages will continue to
use OpenSSL and will not be affected by BoringSSL.

Actually we have already packaged Google's forks of libselinux
<https://packages.debian.org/source/sid/android-platform-external-libselinux>
and libunwind <https://packages.debian.org/source/sid/android-platform-external-libunwind>.
They are isolated from other libraries and won't affect other
packages.

Regards,
Kai-Chung Yan

2016-05-14 4:31 GMT+08:00 Elmar Stellnberger <estellnb@gmail.com>:
>   Just wanted to tell that I am quite happy not to have boringSSL in Debian
> - main. I think it is depeerable there apart from the security risk of
> adopting the SSL package from a company which was largely funded by
> intelligence services and the Pentagon. I would rather like to see OpenBSD`s
> libressl as an option for Debian. I believe the OpenBSD programmers have
> done a pretty good job at it!
>
> Elmar
>
>
> Am 2016-05-13 um 08:44 schrieb Moritz Mühlenhoff:
>>
>> 殷啟聰 <seamlikok@gmail.com> schrieb:
>>>
>>> Dear Debian Security Team,
>>
>>
>> Our contact address is team@security.debian.org, not debian-security...
>>
>>> The "android-tools" packaging team
>>>
>>> <https://qa.debian.org/developer.php?login=android-tools-devel%40lists.alioth.debian.org>
>>> are introducing BoringSSL, a fork of OpenSSL by Google. The latest
>>> Android OS and its SDK no longer use OpenSSL and they use some APIs
>>> only provided by BoringSSL, hence we are bringing BoringSSL to Debian.
>>> You can see the ITP at <https://bugs.debian.org/823933>.
>>
>>
>> No, that's not acceptable. You can try to provide that additional APIs
>> on top of OpenSSL, but we're not going to support an entire OpenSSL
>> fork just for Google's NIH syndrome.
>>
>> Cheers,
>>         Moritz
>>
>



-- 
/*
* 殷啟聰 | Kai-Chung Yan
* 一生只向真理與妻子低頭
* Undergraduate student in National Taichung University of Education
* LinkedIn: <https://linkedin.com/in/seamlik>
* Blog: <http://seamlik.logdown.com>
*/

[toc] | [prev] | [next] | [standalone]

#4789 — Will Packaging BoringSSL Bring Any Good to Debian

[Multipart message — attachments visible in raw view] — view raw

Previous-Subject: Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team?
On Tue, May 17, 2016 at 04:02:37PM +0800, ????????? wrote:
>  ...
> This package places BoringSSL in a private directory which is isolated
> to other libraries, and only Android SDK is using the libraries.

Please put that statement in the long description of the package.
(and continue with packaging BoringSSL)


Regards
Geert Stappers
Who loves to see that Debian is the first choice for Android development

[toc] | [prev] | [next] | [standalone]

#4795

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

[toc] | [prev] | [next] | [standalone]

#4797

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
>

[toc] | [prev] | [next] | [standalone]

#4804

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
>>
> 

[toc] | [prev] | [next] | [standalone]

#4805

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
>>>
>>
> 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web