Today, I learned that a number of versions of git have a potentially serious security flaw. I immediately revised git/package.py to disable the flawed versions, and to make it build good versions by default. @tgamblin seemed to agree that this was a good idea, and he merged the PR. So far so good.

The question is... what next? How will all the Spack users who have already built git and are now using it be informed that they need to rebuild git, and anything that depends_on('git')? And supposing that features are added to Spack that choose packages that have already been built... would that serve to further propagate dependence on bad git versions?

I think we need some kind of infrastructure to deal with this issue in a systematic and thorough fashion. Here is a "first-draft" idea.

Suppose we have a git blacklist that is part of the Spack git repo. The blacklist would be either:

1. As one big file (eg, blacklist.yaml)
2. (Probably better): Within each package.py file, allowing versions to be blacklisted. For example:

class Git(Package):
    """Git is a free and open source distributed version control
       system designed to handle everything from small to very large
       projects with speed and efficiency."""
    homepage = "http://git-scm.com"
    url      = "https://github.com/git/git/tarball/v2.7.1"

    version('2.8.0-rc2', 'c2cf9f2cc70e35f2fafbaf9258f82e4c')
    version('2.7.3', 'fa1c008b56618c355a32ba4a678305f6')
    version('2.7.1', 'bf0706b433a8dedd27a63a72f9a66060')

    # See here for info on vulnerable Git versions:
    # http://www.theregister.co.uk/2016/03/16/git_server_client_patch_now/
    # All the following are vulnerable
    version('2.6.3', 'b711be7628a4a2c25f38d859ee81b423', blacklist=True)
    version('2.6.2', 'da293290da69f45a86a311ad3cd43dc8', blacklist=True)
    version('2.6.1', '4c62ee9c5991fe93d99cf2a6b68397fd', blacklist=True)
    version('2.6.0', 'eb76a07148d94802a1745d759716a57e', blacklist=True)
    version('2.5.4', '3eca2390cf1fa698b48e2a233563a76b', blacklist=True)
    version('2.2.1', 'ff41fdb094eed1ec430aed8ee9b9849c', blacklist=True)

Spack would then have a command ("spack update"?) that would identify any currently-built packages that are now blacklisted, and do what it takes to get rid of them. This would involve re-building anything that depends on them. It is not immediately clear (to me) where or not this step would require manual intervention. Suppose we have installed [email protected], and [email protected] where B depends_on('[email protected]'). And suppose [email protected] is blacklisted. It now becomes impossible to rebuild B when we get rid of the blacklisted [email protected]. Hopefully, B/package.py will have been changed to depends_on some other version of A.

If we want people to notice and respond to blacklisted versions, then it will be important to upgrade our package definitions regularly. Some issues this brings up:

1. Currently, that means upgrading all of Spack with "git update." Maybe that's not so bad. The alternative is to update package definitions separately from spack.
2. Probably best to regularly update released Spack versions with security fixes in the package files. This would need to happen on some regular schedule.