tech-pkg archive

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

Re: not respected: ALLOW_VULNERABLE_PACKAGES=NO




On Sun, Jun 1, 2025 at 3:05 AM Jörg Sonnenberger <joerg%bec.de@localhost> wrote:
On 5/31/25 11:09 PM, George Georgalis wrote:
> On Tue, May 27, 2025 at 3:30 AM Jonathan Perkin via gnats <gnats-
> admin%netbsd.org@localhost <mailto:gnats-admin%netbsd.org@localhost>> wrote:
>  >
>  > The following reply was made to PR pkg/59446; it has been noted by GNATS.
>  > ...
>  >  * On 2025-05-27 at 09:50 BST, Kimmo Suominen via gnats wrote:
>  >
>  >  > You cannot configure pkgin settings in /etc/mk.conf as it has its own
>  >  > configuration files.  I don't think pkgin has a corresponding setting,
>  >  > though.
>  >
>  >  It doesn't, and I have no plans to add one to it, not unless either
>  >  pkg-vulnerabilities is overhauled to provide a scoring system, or the
>  >  vulnerabilities it lists are taken seriously.
>
>
> In the context of enabling pkgsrc's formal approval as enterprise-grade
> package building software, I consider per-package CVE tracking via pkg-
> vulnerabilities essential. This functionality is critical for security
> accounting and oversight at any site using pkgsrc.

The heart of the issue is that the CVE database has become pretty much
useless as metric of security issues for anyone that doesn't sell audit
programs. It is dominated by the semi-automated fuzzing results where
the "reporter" doesn't even spend time to properly analyze the result.
Just as an example, a CVE claiming a buffer overflow in an Endian
conversion function shows a completely lack of understanding of code
structure. Scoring of CVEs is also next-to-useless, some of the worst
security incidents in recent years had only medium score levels.

I'm not saying that pkg-vulnerabilities is useless, but
PKG_ALLOW_VULNERABLE_PACKAGES=no is.

It is what it is. A gated process for site software qualification
is actually very useful when the software has all green lights.
In the cases where it doesn't, I'm looking at how to record
analysis and/or remediation as part of a software approval.

I can see how that would be a mess for building all the packages,
but for two or five dozen speciality packages, having the build
framework and packaging integrated with CVE monitoring and
reporting makes a solution when there otherwise wouldn't be.

Especially when a new CVE can be quickly annotated as
irrelevant or a remediation patch to package built and installed.

-George

--
George Georgalis, (415) 894-2710, http://www.galis.org/



Home | Main Index | Thread Index | Old Index