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


Groups > linux.debian.security > #4805

Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team?

Path csiph.com!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod
From Hans-Christoph Steiner <hans@at.or.at>
Newsgroups linux.debian.security
Subject Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team?
Date Wed, 18 May 2016 12:30:02 +0200
Message-ID <rA6TM-Pd-33@gated-at.bofh.it> (permalink)
References <rye94-59C-5@gated-at.bofh.it> <ryf58-6fM-11@gated-at.bofh.it> <rys2l-2ju-9@gated-at.bofh.it> <rzIeJ-21W-3@gated-at.bofh.it> <rzP6y-6hY-21@gated-at.bofh.it> <rzPge-6lc-11@gated-at.bofh.it> <rA6qK-mg-11@gated-at.bofh.it>
X-Original-To debian-security@lists.debian.org
X-Mailbox-Line From debian-security-request@lists.debian.org Wed May 18 10:21:16 2016
Old-Return-Path <hans@at.or.at>
X-Amavis-Spam-Status No, score=-4.7 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DEPOSIT=2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GMAIL=1, LDO_WHITELIST=-5, MURPHY_DRUGS_REL8=0.02, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=no autolearn_force=no
X-Policyd-Weight using cached result; rate: -7
Dkim-Signature v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=/VDuop1Yax8R683 F3XjVTc0xTTw=; b=cgSEV42nPM9PJDP9nqlaOpLCEq5ldvK58c6+veoTw+D/ryO Vzo0eMcavdgfU9v0brG1uYlfTPU8u7LPoXnmaIwdXcKP/+NFTo7zqBB2YAxa5K1l SUNgGOCQVLtDHlR1w96x0M7Th2SKvpjMXb1QaUHmxG2/DQV4+OgCGHXZlJ6o=
X-Sasl-Enc nccFyYc7HjJ3r05vADBzCEmjgzKFSZAUGwZRmycPMUud 1463566857
X-Enigmail-Draft-Status N1110
Organization @||@
MIME-Version 1.0
Content-Type text/plain; charset=utf-8
Content-Transfer-Encoding 8bit
X-Mailing-List <debian-security@lists.debian.org> archive/latest/27852
List-ID <debian-security.lists.debian.org>
List-URL <https://lists.debian.org/debian-security/>
List-Archive https://lists.debian.org/msgid-search/573C4207.40006@at.or.at
Approved robomod@news.nic.it
Lines 74
Sender robomod@news.nic.it
X-Original-Date Wed, 18 May 2016 12:20:55 +0200
X-Original-Message-ID <573C4207.40006@at.or.at>
X-Original-References <CAKxyyfY1a68Jv=H1qwhGQtLSu2juwGuXa+XTRy_15SHbS4_jZQ@mail.gmail.com> <slrnnjattk.jm1.jmm@inutil.org> <09f531cf-9a33-3a0f-6623-a7918df146a8@gmail.com> <CAKxyyfYXQn+NtefiusHOu+eB_FvhECjm7cj+6aPc6kAy8kN2sA@mail.gmail.com> <9fba7fb2-1c42-11e6-9b6a-00163eeb5320@msgid.mathom.us> <CAJJ2v1WtJqzw1dKqPbq_VykNz1CXSLxXQbv3i3auOhXcOmeA1g@mail.gmail.com> <573C3B3C.6020608@at.or.at>
Xref csiph.com linux.debian.security:4805

Show key headers only | View raw


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

Back to linux.debian.security | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

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

csiph-web