[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How should we handle greenbone-security-assistant?




On 2020, ഡിസംബർ 16 11:57:04 PM IST, Raphael Hertzog <hertzog@debian.org> wrote:
>Hello,
>
>in the pkg-security team we have greenbone-security-assistant (gsa)
>which is a web interface for gvm (former openvas-manager), the
>version currently in Debian no longer works with the latest gvm
>so we have to update it to the latest upstream release... but the
>latest upstream release has significant changes, in particular
>it now relies on yarn or npm from the node ecosystem to download
>all the node modules that it needs (and there are many of them,
>and there's no way that we will package them individually).
>
>The Debian policy forbids download during the build so we can't
>run the upstream build system as is.
>
>As I see it we have three options:
>
>1/ download all the node modules and add them to the source package, but
>then it's just impossible to write a copyright file to document the source
>package. That would be the best option though, the yarn.lock file
>effectively locks a very specific version of each node module so
>even though it's downloaded the net effect is very similar to "vendoring"
>as is done by other projects.

This will only work for a subset of modules because most modules will not be just source (unlike golang), it will contain prebuilt files. The original source is usually ES6 or typescript usually and you need to build them using babel/rollup/typescript.

Though the build tools situation is much better than a few years ago when I started with diaspora and gitlab. I had to start with packaging these tools first.

>2/ disable this download during the package build, move the package
>to contrib, and add some code in the postinst to download the required
>node modules at package installation time (possibly with a debconf
>confirmation prompt and a command that the user can rerun afterwards
>to do it later).

I use this option for gitlab, but I want to eventually move it to main once I package all of them. Out of 1700+ node modules, I'm left with 270+ node modules pulled outside of main. I remove already packaged modules from package.json.

>3/ get rid of greenbone-security-assistant in debian and keep it in kali
>only (all the work I do in pkg-security is part of my Kali work), that
>would be a regression from the current situation and is something that I'd
>like to avoid. We try to contribute back to Debian, but there's only so
>much busy-work that I'm willing to do to achieve this goal.
>
>What option shall we pick?
>
>Shouldn't we relax some requirements to avoid having to resort to that
>kind of hackery?
>
>Cheers,

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


Reply to: