Works for me, thanks!
===> Checking for vulnerabilities in tcpdump-4.99.5
Package tcpdump-4.99.5 has a information-disclosure vulnerability, see
https://nvd.nist.gov/vuln/detail/CVE-2018-19519Package tcpdump-4.99.5 has a out-of-bounds-read vulnerability, see
https://nvd.nist.gov/vuln/detail/CVE-2019-1010220Package tcpdump-4.99.5 has a out-of-bounds-read vulnerability, see
https://nvd.nist.gov/vuln/detail/CVE-2018-19325Package tcpdump-4.99.5 has a out-of-bounds-write vulnerability, see
https://nvd.nist.gov/vuln/detail/CVE-2023-1801ERROR: Define ALLOW_VULNERABLE_PACKAGES in mk.conf or IGNORE_URL in pkg_install.conf(5) if this package is absolutely essential.
*** Error code 1
Stop.
bmake[1]: stopped making "all" in /opt/pkgsrc-stable/net/tcpdump
*** Error code 1
Stop.
bmake: stopped making "all" in /opt/pkgsrc-stable/net/tcpdump
I raised the discussion on tech-pkg but failed to mention a few salient points.
I used LLM to make my comments more concise and clear, I failed to mention that and missed a few language/technical details in my edit, but they are not very important. (LLM is really not clear about "jurisdiction" when it comes to site security and the ecosystem of software.)
Focused observations:
- Per-CVE risk assessment rather than per-package has advantages
- The separation between pkg_add, pkgin, package repos and pkg-vulnerabilities creates potential security blind spots
- audit trails for security-relevant configuration changes, and/or ATF for security feature / unit testing could be helpful
My feeling is pkgsrc should set the right disposition with
regard to security---as a higher priority than adding/fixing packages---even
if the final implementation details are left to site administrators,
the supported security features should work.
In another case, package+CVE exceptions may be needed, since a CVE could apply to a lib with zero consequence in one package, and serious liability in for another... simply adding a per package exception, would create a gap if a new CVE introduced liability---more to consider.
Thanks,
-George
--
George Georgalis, (415) 894-2710,
http://www.galis.org/