Bug#971515: Request for security team input on kubernetes TC bug

2020-11-17 Thread Moritz Mühlenhoff
On Sun, Nov 08, 2020 at 10:49:31PM +0100, Florian Weimer wrote:
> * Moritz Mühlenhoff:
> 
> > * Follow a scheme similar to Firefox ESR where in case of a security
> >   the update either happens to the latest minor release of
> >   the current branch or if that has stopped, happens to the next
> >   major release. To map this to specific k8s releases: Let's assume bullseye
> >   were already stable and would ship 19.3. In three months a security issue
> >   arises which is severe enough to warrant an update and we ship 19.5
> >   in a DSA. Fast forward 6 months and 19.x is EOLed, but some severe
> >   security issue needs to be fixed; then the bullseye update would move
> >   to 20.1 or so. That sounds unusual for a Debian release, but it's
> >   the status quo for _any_ Kubernetes user after all (whether deployed
> >   on premises or at some "cloud vendor").
> 
> Another thing to consider: Kubernetes rebases will likely require Go
> rebases, if I read this table correctly:
> 
> <https://github.com/kubernetes/community/blob/master/contributors/devel/development.md#go>

I can't tell how strict these requirements are in practice.

It's similar to Firefox requiring more recent versions of rustc and
golang packages are co-installable, so when it comes to that, shipping
a new golang-x.y package might also be an option.

> Since Go has a bit of spotty history in terms of kernel backwards
> compatibility, this could cause further challenges.

Do you have a concrete example of such a change? I see that 1.14 is available
in backports, so this seems to work out so far.

Cheers,
Moritz



Bug#971515: Request for security team input on kubernetes TC bug

2020-11-17 Thread Moritz Mühlenhoff


Catching up on this...

> > This leaves Debian with two options:
> > * Keep it out of a stable release and accept that it's good enough
> >   if people just install whatever deb they currently find in testing/sid
> >   (works out well enough for most given that blob nature of Go!)
> 
> IMHO this is the most reasonable option and perhaps the only viable one.

Ultimately that's for the release team and/or CTTE to make a call on.

And this while discussion also needs the input of Janos as the current 
kubernetes
maintainer.

> > * Follow a scheme similar to Firefox ESR where in case of a security
> >   the update either happens to the latest minor release of
> >   the current branch or if that has stopped, happens to the next
> >   major release.
> 
> I think Kubernetes have many more vendored 3rd party libraries than Firefox.
> IMHO we can not expect the same level of confidence for Kubernetes...

But each of their releases constitutes a bundle of third party libraries
they've vetted to work together, so this seems to work in practice? (as
can be seen by the 1.19 upload from today). Or maybe I'm missing the specific
concern of yours, is this about them missing fixes in their bundled libs?

Cheers,
Moritz



Bug#971515: Request for security team input on kubernetes TC bug

2020-10-27 Thread Moritz Mühlenhoff
On Wed, Oct 21, 2020 at 08:22:11AM -0700, Sean Whitton wrote:
> Hello security team,
> 
> The TC are being asked about src:kubernetes, and it would be good to
> hear from you about whether and how security support is a relevant
> consideration in determining whether the level of vendoring in that
> package is acceptable.  Could you take a look at #971515 and perhaps
> give us some input, please?

I don't currently have the time to read through all the discussion backlog,
but let me try to "zoom out a bit":

The bigger issue here (independent of the whole vendoring aspect) is
how kubernetes can be supported in a stable release to begin with.
This was raised by Shengjing Zhu in #959685 before.

Upstream support only lasts for up to a year and it would be
presumptuous to pretend that we can seriously commit to fix
security issues in k8s for longer than upstream.

This leaves Debian with two options:
* Keep it out of a stable release and accept that it's good enough
  if people just install whatever deb they currently find in testing/sid
  (works out well enough for most given that blob nature of Go!)
* Follow a scheme similar to Firefox ESR where in case of a security
  the update either happens to the latest minor release of
  the current branch or if that has stopped, happens to the next
  major release. To map this to specific k8s releases: Let's assume bullseye
  were already stable and would ship 19.3. In three months a security issue
  arises which is severe enough to warrant an update and we ship 19.5
  in a DSA. Fast forward 6 months and 19.x is EOLed, but some severe
  security issue needs to be fixed; then the bullseye update would move
  to 20.1 or so. That sounds unusual for a Debian release, but it's
  the status quo for _any_ Kubernetes user after all (whether deployed
  on premises or at some "cloud vendor").

If we follow the latter approach, then the current way k8s is packaged
is the only viable option (as otherwise the run time deps shipped
for 19.x would be incompatible with 20.x etc.)

Cheers,
Moritz



Bug#947847: please install systemd-sysusers using update-alternatives

2020-01-29 Thread Moritz Mühlenhoff
Simon McVittie wrote:
> I think we have a fairly good picture of the costs that would be
> incurred from using alternatives:

Plus in the case of opentmpfiles; a pile of security issues: systemd-tmpfiles
addresses a number of complex races using low level primitives like openat() et
al. or O_PATH, while opentmpfiles is implemented in shell.

Cheers,
Moritz




Bug#802159: New OpenSSL upstream version

2015-12-06 Thread Moritz Mühlenhoff
Hi,
Personally I'm in favour of following the openssl point updates and I'd
like to add an additional data point to the discussion:

CVE-2015-3196 was already fixed as a plain bugfix in an earlier point
release, but the security impact was only noticed later on, so following
the point updates would have fixed this bug five months ago.

(http://www.openssl.org/news/secadv/20151203.txt for details)

Cheers,
Moritz



Bug#727708: systemd (security) bugs (was: init system question)

2013-11-30 Thread Moritz Mühlenhoff
On Thu, Nov 28, 2013 at 08:07:16PM -0600, Steve Langasek wrote:
 All distributions care about not having security issues in their code, but
 that's not the same thing as actually doing the work to audit the code.  In
 practice this only happens when dedicated resources are turned on the code
 in question, and having more companies using the code does not magically
 make that happen.

[I took care of the systemd DSA people are referring to]

The issue people are talking about were discovered during a review of
the Red Hat Product Security Team (most likely triggered by the inclusion
of systemd into RHEL7).
So in fact having more companies use the code exactly made that magically
happen.

For every complex code base a thorough review will unveil security-related
implementation bugs and the ones found for systemd are not exactly earth-
shattering.

More review and more usage will lead to more bugs being found, we should
rather applaud Red Hat for investing resources and be diligent. After all
Red Hat is the only distro staffing a proactive product security team
(from which everyone is profiting outside of RH as well). I don't consider
the lack of reported security issues for the contenders as a credible 
indication of them being more secure.

FWIW, the main reason I'm personally in favour of adopting systemd is precisely 
security (in terms of sandboxing and restricting services). See
http://0pointer.de/blog/projects/security.html for some pointers.

[EOD from me due to a lack of time, but that needed to be said]

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131130150714.GA4204@pisco.westfalen.local