Re: What can Debian do to provide complex applications to its users?
On Mon, Feb 19, 2018 at 09:18:13AM +0100, Philipp Kern wrote:
> On 2018-02-18 22:53, Adrian Bunk wrote:
> > In the year 2018, any kind of "properly maintain" includes security
> > support.
> >
> > Please elaborate how Debian can provide security support for packages
> > like gitlab and all their dependencies in buster until mid-2022.
> >
> > If Debian cannot provide security support for the lifetime of a stable
> > Debian release, it is better for our users when they are installing the
> > software from upstream with the security support provided by upstream.
>
> Putting security support over all else is surely how some people see it. But
> some upstreams also complain if you are going to ship ancient versions
> because the most recent ones contain all of the fixes. It's certainly more
> work to validate security fixes when backporting them to older versions. So
> it's also the "stable" guarantee (whatever it is seen as) that might need
> some re-adjustment.
Every change that gets published as DSA or part of a stable update gets
automatically installed on millions of machines.
> One of the values is that you get some set of software that works together
> as a base and doesn't change, but then people install software on top of it
> that provides their service and if it's actually the thing they want to
> provide it's most likely not packaged anymore at this point. Because you'd
> want the latest features of the product you're using.
Sometimes that is true and sometimes it is not.
And what are the latest features today will likely be included in the
version in the next Debian stable.
The main question is what Debian can offer throughout the distribution.
Installing some or few (open source or proprietary) products on top of
the distribution is often required for various reasons.
If Debian ships an older version of one of these products that is not
a problem.
What is a problem is if such a 3rd party product suddenly breaks due
to an update in the stable distribution, or becomes vulnerable due to
unfixed CVEs in the stable distribution.
> So there's already a
> disconnect of essentially two tracks: the system's base at a solid version
> and whatever it is you want to offer at a fast moving pace. That's also a
> reality in 2018. And coming up with arbitrary deadlines of support are not
> all that helpful. Users don't care if the ancient version of the software
> they need in stable is security supported until mid-2022. If it doesn't
> satisfy their requirements anymore, they move to testing or to another
> distribution.
Let's make a real-life example:
salsa.debian.org and gitlab.
salsa currently runs a manually installed gitlab.
At some point after the release of buster salsa is expected to be
upgraded to buster.
If buster ships a gitlab package with no security support from Debian,
would you recommend that Debian uses this package on salsa until
bullseye gets released?
If buster ships a gitlab package that is supported by Debian by every
once in a while upgrading to the latest upstream gitlab, would you
recommend that Debian uses this package on salsa instead of continuing
to use a manually installed gitlab?
Even if gitlab would have been part of stretch it is clear that salsa
wouldn't use the version in stretch. The "ancient version of the
software" in buster will likely be recent enough for salsa, but for
such a central and exposed service security support and no regressions
are also important.
> Kind regards
> Philipp Kern
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: