pkg/32092: audit-packages version skew breaks badly

[dholland%eecs.harvard.edu@localhost]

>Number:         32092
>Category:       pkg
>Synopsis:       audit-packages version skew wedges package system
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Nov 17 00:04:00 +0000 2005
>Originator:     David A. Holland <dholland%eecs.harvard.edu@localhost>
>Release:        NetBSD 2.0 (pkgsrc of 20051116)
>Organization:
    Harvard EECS        
>Environment:
System: NetBSD rhett 2.0 NetBSD 2.0 (GENERIC) #0: Wed Dec 1 10:58:25 UTC 2004 
builds@build:/big/builds/ab/netbsd-2-0-RELEASE/i386/200411300000Z-obj/big/builds/ab/netbsd-2-0-RELEASE/src/sys/arch/i386/compile/GENERIC
 i386
Architecture: i386
Machine: i386
>Description:
        If audit-packages is out of date, the ALLOW_VULNERABILITIES.*
        logic breaks.

        In particular, I had last updated anything on this machine
        sometime in August, and after cvs updating pkgsrc tonight I
        got bitten by this.

        It wedged the package system: before I could install anything
        else, I had to update pkg_install, but I couldn't update
        pkg_install either because the build system thought that some
        unrelated vulnerabilities in other packages pertained to it.

        Somewhat relatedly, audit-packages seems to depend on itself:
        as part of an unwise workaround attempt I pkg_delete'd it, and
        now that I have pkg_install updated I get this:

rhett# cd security/audit-packages
rhett# make update
===> Checking for vulnerabilities in audit-packages-1.40
===> *** The audit-packages package must be at least version 0.40
===> *** Please install pkgsrc/security/audit-packages package and run
===> *** '/usr/pkg/sbin/download-vulnerability-list'.
*** Error code 1

        Additionally, after this message one gets

or if this package is absolutely essential, add this to mk.conf:
 ALLOW_VULNERABILITIES.audit-packages+====>
 ALLOW_VULNERABILITIES.audit-packages+=CVS
 ALLOW_VULNERABILITIES.audit-packages+=DESCR
 ALLOW_VULNERABILITIES.audit-packages+=MESSAGE
 ALLOW_VULNERABILITIES.audit-packages+=Makefile
 ALLOW_VULNERABILITIES.audit-packages+=PLIST
 ALLOW_VULNERABILITIES.audit-packages+=README.html
 ALLOW_VULNERABILITIES.audit-packages+=files
 ALLOW_VULNERABILITIES.audit-packages+=work
 ALLOW_VULNERABILITIES.audit-packages+=The
 ALLOW_VULNERABILITIES.audit-packages+=audit-packages
 ALLOW_VULNERABILITIES.audit-packages+=package
 ALLOW_VULNERABILITIES.audit-packages+=must
        :

        that is, the error message is being mishandled. And in the
        process it seems to have been globbed by the shell, which is
        itself probably a bad sign.

>How-To-Repeat:

        Get a suitably old version of audit-packages (my guess is that
        reverting version 1.24 of security/audit-packages/files/audit-packages
        will do the trick), install some package with a known vulnerability,
        and try to build pkg_install. It might also be necessary to revert
        pkg_install. (The previous version I had was, I believe, 20050718.)

        I haven't actually tested this.

        (To repeat the audit-packages problem, it should be sufficient
        to pkg_delete it and attempt to reinstall it using today's
        pkgsrc.)

>Fix:
        Most importantly, the proper workaround for the problem
        is to delete everything but the header from the package
        vulnerabilities file, update pkg_install and audit-packages,
        then rerun download-vulnerability-list. I haven't actually
        tried this but it should do the trick.

        Deleting audit-packages to try to disable or fake out the
        check was clearly the wrong idea. :-/

        The proper fix:

        1. pkg_install and audit-packages should always skip the
           vulnerability check.

        2. Setting ALLOW_VULNERABLE_PACKAGES=1 should still skip the
           vulnerability check. Right now, it doesn't.

           While it might be possible to work around the problem using
           the new ALLOW_VULNERABILITIES logic, that's far from clear
           and it's not at all obvious at this stage what the right
           incantation would be. What the system suggests has the same
           form as the paste above.

           (Also, ALLOW_VULNERABLE_PACKAGES will still be useful for
           once-off builds.)

        3. The check that the version of audit-packages is >= 0.40
           was presumably meant to be 1.40. Either that or it needs to
           be updated.

        4. ...and obviously the problem with the adding-to-mk.conf
           message ought to be straightened out, too.