Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.security > #4805
| 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 | 2016-05-18 12:30 +0200 |
| Message-ID | <rA6TM-Pd-33@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <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> |
| Organization | @||@ |
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
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