tech-pkg archive

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

Re: Switch vulnerable packages to a warning only



* On 2020-05-21 at 17:12 BST, Greg Troxel wrote:

> coypu%sdf.org@localhost writes:
> 
> > Over time, more packages, and more essential packages are considered
> > vulnerable. Unfortunately this makes users suffer unnecessarily for
> > fetching the package vulnerability database.
> >
> > I assume most people who ran "pkg_admin fetch-pkg-vulnerabilities" have
> > immediately had to add ALLOW_VULNERABLE_PACKAGES=yes to mk.conf
> >
> > So, I am proposing a user-friendliness step of only warning about
> > vulnerable packages by default.
> >
> > Thoughts?
> >
> > Index: pkgformat/pkg/check.mk
> > ===================================================================
> > RCS file: /cvsroot/pkgsrc/mk/pkgformat/pkg/check.mk,v
> > retrieving revision 1.1
> > diff -u -r1.1 check.mk
> > --- pkgformat/pkg/check.mk	15 Oct 2011 00:23:09 -0000	1.1
> > +++ pkgformat/pkg/check.mk	21 May 2020 15:56:15 -0000
> > @@ -20,6 +20,5 @@
> >  		exit 0;						\
> >  	fi;							\
> >  	${PHASE_MSG} "Checking for vulnerabilities in ${PKGNAME}"; \
> > -	${AUDIT_PACKAGES} ${_AUDIT_PACKAGES_CMD} ${AUDIT_PACKAGES_FLAGS} ${PKGNAME} \
> > -	|| ${FAIL_MSG} "Define ALLOW_VULNERABLE_PACKAGES in mk.conf or ${_AUDIT_CONFIG_OPTION} in ${_AUDIT_CONFIG_FILE}(5) if this package is absolutely essential."
> > +	${AUDIT_PACKAGES} ${_AUDIT_PACKAGES_CMD} ${AUDIT_PACKAGES_FLAGS} ${PKGNAME} || ${TRUE}
> >  .endif
> 
> As someone who sets the variable, I am very sympathetic.  I think it's
> good to have the option to be strict, even if I'm not sure there are any
> actual people who use that.

I'm not sure it's possible anyone _can_ use it.  Given:

  Package libarchive-3.4.0nb1 has a out-of-bounds-read vulnerability
  Package libarchive-3.4.0nb1 has a invalid-validation vulnerability

I don't see that anyone can even bootstrap with it set, unless they
are using builtin libarchive.

And even if they get bootstrapped, they aren't going to get very far:

  Package icu-66.1 has a integer-overflow vulnerability
  Package libxml2-2.9.10nb1 has a buffer-overflow vulnerability
  Package perl-5.30.2 has a symlink-attack vulnerability
  Package python27-2.7.18 has a denial-of-service vulnerability
  Package python37-3.7.7 has a crlf-attack vulnerability
  Package python37-3.7.7 has a denial-of-service vulnerability
  ...

It's a nice idea, but with the current state of affairs it's
completely unrealistic as an option, and certainly as a default one.

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com


Home | Main Index | Thread Index | Old Index