Re: How should we handle greenbone-security-assistant?
On Thu, Dec 17, 2020 at 02:55:11PM +0100, Raphael Hertzog wrote:
>...
> By trying to shoehorn node/go modules into Debian packages we are creating
> busy work with almost no value. We must go back to what is the value
> added by Debian and find ways to continue to provide this value while
> accepting the changed paradigm that some applications/ecosystems have
> embraced.
>
> And for me selling points are:
>...
> - 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?
> (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.
>...
> We must go back to what is the value
> added by Debian and find ways to continue to provide this value while
> accepting the changed paradigm that some applications/ecosystems have
> embraced.
>...
> - security support
> => we need to be able to identify packages that are vulnerable because
> they have embedded a problematic version of a node/go module, again we
> need tools that analyze what got embedded in the binary package and make
> this easy to query
>...
This is the easy part.
How do you plan to fix all vulnerable versions?
If the tooling tells you that we have 100 copies of OpenSSL
in 70 different versions across the archive, this means you
also have to do the actual work of fixing every single one
each time there is a new CVE.
This is not a purely hypothetical example, I have seen OpenSSL
vendored in such "changed paradigm" ecosystems.
> Cheers,
cu
Adrian
Reply to: