Re: How should we handle greenbone-security-assistant?
On Thu, 17 Dec 2020, Pirate Praveen wrote:
> > - 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.
I don't think so. First the tool is here to help the maintainer do the
assertion, it's unlikely to be 100% automated, it will likely point
out files to inspect manually and so on.
And, as a user, even if the tool exists, I wouldn't want to run it manually,
I would continue to rely on Debian for the vetting process. I don't want
to have to do this on my own.
> > => 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.
For this to work at scale, you need to work with the upstream ecosystem so
that this works out of the box... AFAIK right now adding the required node
modules in build-depends will not avoid those modules to be downloaded by
the upstream build system and there's no simple flag that you can just add
to enable that behaviour. Is that correct ?
> > - 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?
I don't know for you but the reasons to use Debian would not be changed
by the addition of this mechanism. I know that I use only free software,
that all the tools are easy to install, that some sane default
configuration has been provided by the maintainer, that further
instructions are in README.Debian, etc.
> 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.
This I agree with. And I believe it still stays true even if we accept to
vendor large amount of stuff.
> We need to be doing what is the buzz of the time. Free Software was not a
> mainstream idea when we started.
I don't understand what you are trying to say here.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Reply to: