Re: How should we handle greenbone-security-assistant?
On Thu, Dec 17, 2020 at 2:55 pm, Raphael Hertzog <hertzog@debian.org>
wrote:
I know this, but I also know that such an analysis is very
time-consuming
and needs a good knowledge of the language and of the upstream
package,
which I don't have.
Most of the time Semantic Versioning works (https://semver.org) so you
don't really need to know the code.
In your original post you seemingly already ruled out proper
packaging
as a premise, and it seems you continue to use absolutes like
"everything" and "never". I find that discouraging - plase
consider a
less negative tone.
Sorry, I don't want to discourage you. But I'm also sure that I will
never
be able to justify spending days and weeks on packaging (and then
maintaining) all those node modules for the benefit of pushing a
single
package to Debian when said package was updated in Kali in a matter of
hours.
Though that is not entirely correct. Many of the build tools and
libraries I had to package for gitlab are reused by other packages.
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:
- ensurance that we use DFSG free code only
=> we can have tool to review licenses of what has been
downloaded during build and embedded in the binary packages
Then there would not be any value for Debian with such a scenario as
people can do such analysis on any distro/container.
It would make debian irrelevant.
- ease of installation and reliability
=> we are doing bad now because many useful things are not packaged
(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...
This I agree, but this could be achived by a mix of vendoring and
individual packages. We can vendor modules that are specific to a
single app and package more useful libraries as individual packages.
- possibility to rebuild from source
=> we could have some sort of proxy that would store everything
downloaded and let us rebuild an identical package without net
access
even if the remote resources disappear
Why would anyone need to use debian in such a scenario?
All the current trends are making it easy for developers to ship code
directly to users. Which encourages more isolation instead of
collaboration between projects. It also makes it easy for shipping more
proprietary code, duplication of security tracking or lack of it.
Debian and other distributions have provided an important buffer
between developers and users as we did not necessarily follow the
priorities or choices of upstream developers exactly always.
We need to be doing what is the buzz of the time. Free Software was not
a mainstream idea when we started.
Reply to: