Re: How should we handle greenbone-security-assistant?
On Fri, Dec 18, 2020 at 09:11:42AM +0100, Raphael Hertzog wrote:
> On Thu, 17 Dec 2020, Adrian Bunk wrote:
> > > - ease of installation and reliability
> > > => we are doing bad now because many useful things are not packaged
> >
> > What is the value added just by installing things through dpkg instead
> > of npm?
>
> Why are you using Debian if you ask this?
I am using Debian on my desktop and Ubuntu on my laptop for having
a stable and security-supported environment.
> On the top of my head:
> - as a user, I like to have to only know about "apt/dpkg" instead
> of pip/npm/gem/...
This sounds as if you are making the case for a higher level tool
that calls lower level tools like apt and npm.
> - the Debian maintainer is ensuring some consistency that a random
> collection of uptsream installations are not enusring
>...
Tools like npm can actually give more consistency by pinning all
dependencies to exact versions.
For security support this is a nightmare, but for consistency it is better.
> > > (due to the mismatch between our rules and those not-longer-so-new
> > > ecosystems) and when users have to manually install, the reliability
> > > goes down...
> >
> > What reliability do you have with a 3 year old version of software where
> > upstream only tells your users to upgrade to the latest versions?
> >
> > The "changed paradigm" usually includes automatic updates to the latest
> > version without any maintainance of older versions.
>
> Indeed. We should have room for such software that should only be provided
> within our rolling distribution and as backports.
Such software should not be provided in backports.
The point of backports is that our users can cherry-pick software that
will be shipped in the next stable release, after upgrading to the next
stable release all backports should be upgraded to the version in the
new stable where they are (security) supported.
bullseye-backports is really supposed to be a subset of what will be
in the final bullseye release, software that is not expected to be in
the next stable release does not belong there.
There is surely a need for PPAs for such software in Debian,
but this is a usecase different from backports.
> > This is the easy part.
> > How do you plan to fix all vulnerable versions?
>
> By providing the latest and greatest version to all our users. As you
> noticed, that kind of software does not mesh well with stable and LTS.
>...
That kind of software does not mesh well with wanting security fixes.
The "changed paradigm" you are pushing includes shipping of vendored
dependencies pinned to ancient versions - often without caring about
vulnerabilities.
As a random example, src:rustc in Debian ships a vendored copy of a 2017
version of src:rust-yaml-rust to which it is pinned and which is missing
CVE fixes. I do not know whether they are relevant for rustc or whether
this vendored code is used at all, but this is the latest upstream
version of rustc and the CVEs are from 2018 and 2019.
> Cheers,
cu
Adrian
Reply to: