{"action":"created","issue":{"url":"https://api.github.com/repos/LLNL/spack/issues/562","repository_url":"https://api.github.com/repos/LLNL/spack","labels_url":"https://api.github.com/repos/LLNL/spack/issues/562/labels{/name}","comments_url":"https://api.github.com/repos/LLNL/spack/issues/562/comments","events_url":"https://api.github.com/repos/LLNL/spack/issues/562/events","html_url":"https://github.com/LLNL/spack/issues/562","id":141439341,"number":562,"title":"Security Updates","user":{"login":"citibeth","id":1924215,"avatar_url":"https://avatars.githubusercontent.com/u/1924215?v=3","gravatar_id":"","url":"https://api.github.com/users/citibeth","html_url":"https://github.com/citibeth","followers_url":"https://api.github.com/users/citibeth/followers","following_url":"https://api.github.com/users/citibeth/following{/other_user}","gists_url":"https://api.github.com/users/citibeth/gists{/gist_id}","starred_url":"https://api.github.com/users/citibeth/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/citibeth/subscriptions","organizations_url":"https://api.github.com/users/citibeth/orgs","repos_url":"https://api.github.com/users/citibeth/repos","events_url":"https://api.github.com/users/citibeth/events{/privacy}","received_events_url":"https://api.github.com/users/citibeth/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2016-03-17T00:14:44Z","updated_at":"2016-03-29T21:22:25Z","closed_at":null,"body":"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.\r\n\r\nThe 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?\r\n\r\nI think we need some kind of infrastructure to deal with this issue in a systematic and thorough fashion.  Here is a \"first-draft\" idea.\r\n\r\nSuppose we have a git blacklist that is part of the Spack git repo.  The blacklist would be either:\r\n  1. As one big file (eg, blacklist.yaml)\r\n  2. (Probably better): Within each package.py file, allowing versions to be blacklisted.  For example:\r\n\r\n```\r\nclass Git(Package):\r\n    \"\"\"Git is a free and open source distributed version control\r\n       system designed to handle everything from small to very large\r\n       projects with speed and efficiency.\"\"\"\r\n    homepage = \"http://git-scm.com\"\r\n    url      = \"https://github.com/git/git/tarball/v2.7.1\"\r\n\r\n    version('2.8.0-rc2', 'c2cf9f2cc70e35f2fafbaf9258f82e4c')\r\n    version('2.7.3', 'fa1c008b56618c355a32ba4a678305f6')\r\n    version('2.7.1', 'bf0706b433a8dedd27a63a72f9a66060')\r\n\r\n    # See here for info on vulnerable Git versions:\r\n    # http://www.theregister.co.uk/2016/03/16/git_server_client_patch_now/\r\n    # All the following are vulnerable\r\n    version('2.6.3', 'b711be7628a4a2c25f38d859ee81b423', blacklist=True)\r\n    version('2.6.2', 'da293290da69f45a86a311ad3cd43dc8', blacklist=True)\r\n    version('2.6.1', '4c62ee9c5991fe93d99cf2a6b68397fd', blacklist=True)\r\n    version('2.6.0', 'eb76a07148d94802a1745d759716a57e', blacklist=True)\r\n    version('2.5.4', '3eca2390cf1fa698b48e2a233563a76b', blacklist=True)\r\n    version('2.2.1', 'ff41fdb094eed1ec430aed8ee9b9849c', blacklist=True)\r\n```\r\n\r\nSpack 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 A@1.5, and B@2.0 where B depends_on('A@1.5').  And suppose A@1.5 is blacklisted.  It now becomes impossible to rebuild B when we get rid of the blacklisted A@1.5.  Hopefully, B/package.py will have been changed to depends_on some other version of A.\r\n\r\nIf 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:\r\n 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.\r\n 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.\r\n"},"comment":{"url":"https://api.github.com/repos/LLNL/spack/issues/comments/203110763","html_url":"https://github.com/LLNL/spack/issues/562#issuecomment-203110763","issue_url":"https://api.github.com/repos/LLNL/spack/issues/562","id":203110763,"user":{"login":"dshrader","id":1985961,"avatar_url":"https://avatars.githubusercontent.com/u/1985961?v=3","gravatar_id":"","url":"https://api.github.com/users/dshrader","html_url":"https://github.com/dshrader","followers_url":"https://api.github.com/users/dshrader/followers","following_url":"https://api.github.com/users/dshrader/following{/other_user}","gists_url":"https://api.github.com/users/dshrader/gists{/gist_id}","starred_url":"https://api.github.com/users/dshrader/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dshrader/subscriptions","organizations_url":"https://api.github.com/users/dshrader/orgs","repos_url":"https://api.github.com/users/dshrader/repos","events_url":"https://api.github.com/users/dshrader/events{/privacy}","received_events_url":"https://api.github.com/users/dshrader/received_events","type":"User","site_admin":false},"created_at":"2016-03-29T21:22:25Z","updated_at":"2016-03-29T21:22:25Z","body":"I am a proponent of the user making the choice on what to do with blacklisted packages. In general, though, given the amount of variability in this space, it might be too big of a thing for Spack to tackle, as you mentioned @citibeth . A vulnerability in git isn't the same thing as a vulnerability in openssl (unless, of course, it is!).\r\n\r\nPerhaps it might be better to punt this one to the users of Spack. They had to keep up with acceptable versions of their software and its dependencies before Spack, we may just have to have them keep doing it with Spack. Of course, we can make it easier for them to build replacements, so it may still be beneficial to provide means by which software can be removed and/or replaced at the user's request."}}