On Tue, May 27, 2025 at 3:30 AM Jonathan Perkin via gnats <
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.
My original bug report highlighted a concerning issue: despite explicitly setting ALLOW_VULNERABLE_PACKAGES=NO in a pristine bootstrap, vulnerable packages were unexpectedly deployed. While I don't expect pkgin to act as a gatekeeper for pkg-vulnerabilities, this data point revealed a significant build and install workflow security gap.
From a security-conscious perspective, the chain from CVE publication to pkgsrc vulnerability auditing is imperative. This signaling helps sites assess threat exposure, even when internal security policies cannot be publicly disclosed.
@jperkin, I understand that the lack of a scoring system may create frustration or suggest security isn't taken seriously. However, I advocate for a deterministic approach, because there are far more potential vulnerabilities across all software than those posing specific threats within given implementations; there is no need to mitigate CVE at all sites where the vulnerability does not pose a threat. My approach is to identify each CVE as critical, mitigated, or irrelevant to site criteria; and I recognise this tooling as less effort and more effective when there is a uniform and finite package set, like pkgsrc provides.
Whether commiting the barrier reset of ALLOW_VULNERABLE_PACKAGES was an honest mistake, an artifact of inconvenient security barriers posed while fixing a vulnerability, or an intentional covert action through a compromised account (very unlikely given the commit circumstance), my reaction remains the same: implement more accessible security cross-checks (easier to use), rather than abandoning existing security frameworks.
This bug has uplifted my understanding of pkgsrc's phase barrier mechanism. Since the actual problem is the lack of an easy to use exception system, I recommend the following security strategy improvements:
- Phase Barrier Checks: Use vulnerability lists to identify threats at relevant phase barriers
- Flexible Controls: Enable optional CVE check, warning, and/or block mechanisms
- Exception Management: Implement a CVE exception matrix for analysis and remediation documentation
Many packages may have CVE irrelevant to local implementations due to:
- Sufficient separation between the threat vector and actual usage
- Vulnerable features being disabled in the implementation
- Accepted risk based on security assessment
- Trusted user environments
I propose an exception system, triggered through a $LOCALBASE/etc/CVE-exception file, with the following format:
CVE-2021-36159 remediated by hash checking downloaded files; ops-critical-683b5854
where only detection of arg1 is required to pass that CVE check, when
ALLOW_VULNERABLE_PACKAGES=NO
This deterministic approach offers several advantages:
- Provides a required CVE check process, for compliance at many sites
- Easier to implement than score-based systems
- Trivial to disable for sites not requiring it (not enabled by default)
- Simple to maintain exception records
- Compatible with third-party scoring systems, and post install re/analysis
While not originally intended, the ability for pkgin to check:
- Package repositories against vulnerability lists
- Individual packages at install time
would provide valuable security coverage, especially as gaps arise in the time between package builds and installations.
While pkg_admin audit is valuable for checking installed packages for new vulnerabilities, it would seem appropriate for at least one of pkgin, pkg_add, or pkg_admin to support checking packages in configured repos against the pkg-vulnerabilities file too? And/or support a configuration to block packages matching pkg-vulnerabilities file when attempting to install them?
The economy of a shared $LOCALBASE/etc/CVE-exception file should be self-evident.
This approach balances security requirements with practical implementation concerns, providing sites with the tools needed for proper vulnerability management while maintaining flexibility for different security postures.
@kim, thanks for your research, identifying the bug, the commit
and creating the pkg/59446 patch!
I hope it makes it into pkgsrc-2025Q2!
-George
Log Message:
bsd.pkg.barrier.mk: Do not set ALLOW_VULNERABLE_PACKAGES to empty
Setting ALLOW_VULNERABLE_PACKAGES to an empty value for recursive make
calls effectively prevents using the option.
Tested with a local build of select packages with no ill effects
observed.
The explicit setting to empty was introduced when
bsd.pkg.barrier.mk was
created in July of 2006. It does not appear to have been carried over
from any code replaced by
bsd.pkg.barrier.mk. Unfortunately there is no
comment or mention in the commit message about this.
--
George Georgalis, (415) 894-2710,
http://www.galis.org/