security/vuls: Update to 0.4.0

[ultima]

Summary

Update to 0.4.0, reordered tuple alphabetically for sanity and cleanup fixed items upstream

PR\: 221868
Submitted by\: Alexandru Ciobanu (maintainer)
Reviewed by\: lifanov (mentor), matthew (mentor)
Approved by\: lifanov (mentor), matthew (mentor)
Differential Revision\: https://reviews.freebsd.org/DXXXXX

Test Plan

portlint:
WARN: Makefile: for new port, make $FreeBSD$ tag in comment section empty, to make SVN happy.
0 fatal errors and 1 warning found.

poudriere:
103i386
103amd64
110i386
110amd64
12i386
12amd64

[matthew]

security/vuls/files/patch-commands_configtest.go

18 ↗

(On Diff #32598)

Careful now -- looks like you've lost the %%ETCDIR%% substitution to adapt the port to variant $PREFIX settings.

This is a flaw in what make makepatch does -- any post-patch substitution step tends to get wiped out.

security/vuls/files/patch-commands_report.go

10 ↗

(On Diff #32598)

%%ETCDIR%% again here

security/vuls/files/patch-commands_scan.go

10 ↗

(On Diff #32598)

and %%ETCDIR%% here as well?

[ultima]

security/vuls/files/patch-commands_configtest.go

18 ↗

(On Diff #32598)

Yeah I noticed this before I submitted, was it okay to have these values hardcoded or is this the preferred method? or does it matter? I just forgot to remove the REINPLACE_CMD.

[matthew]

security/vuls/files/patch-commands_configtest.go

18 ↗

(On Diff #32598)

Hard-coding is a no-no. You are always meant to be able to use a custom $PREFIX.

Patching in a replaceable token and then substituting in the current value of $PREFIX is a well known pattern.

[ultima]

Removed hardcoded change

[ultima]

security/vuls/files/patch-commands_configtest.go

18 ↗

(On Diff #32598)

I must be getting some use case mixed up for something like /var/db or /var/log.

[lifanov]

The /var/db and /var/log stuff is OK to have hardcoded, but anything under /usr/local (like ETCDIR) is not.

[matthew]