Proposal: tracking security holes and major bugs with Stackage and Stack

proposal.md

Goals

• Allow a systematic way for community members to report security holes and major bugs in a specific version of a package
• Providing meaningful information to end users about this
• Make the process for reporting this lightweight
• Leverage existing information when possible
• Allow for easy integration with tooling to give users warnings of problems

Proposal

1. Add a new file to the stackage repo called bugs.yaml, with a very simple format such as:

   - package: foo
     versions:
     - 1.0.0
     - 1.0.1
     - == 0.9.*
     reason: Remote execution hole
     urls:
     - https://github.com/foo/foo/issues/51
     date: 2016-06-09
     # Maybe other metadata fields, like severity and type (security/runtime/compile time)

   • Alternatively may be tracked in a separate repository

2. Define rules for who is allowed to make such additions and how pull requests are handled. Initially, we should likely be very liberal with accepting additions, and become more strict over time as the list grows.

3. Treat both the newly created YAML file and Hackage deprecations as upstream data sources for a list of all package/version combos that should be untrusted. Serve that from somewhere (strawman: stackage.org)

End users

• Create a website and RSS feed for this information
• Possibly allow to filter by metadata (e.g., only show me security flaws)
• People will of course be free to post these announcements on mailing lists/Reddit/Twitter, but that won't be something we do automatically

Tooling

• When we run stack update (or it is implicitly run when an index needs to be updated) it will download the full list of blocked packages (i.e., both the YAML file and Hackage deprecations)
• Each time a user runs stack build, it will check if any of the versions used in the project are on the blocked list, and will give the user a large warning
• Possibly: add a configuration value or flag to turn these warnings into errors
• Add ability to mark certain package/version combos as vetted and thereby override the blocked status from upstream (e.g., "I know this package has a bug in function X, but we never use it)
• Other tools like cabal-install are free to add this support as well

There's a discussion of this on Reddit at:

https://www.reddit.com/r/haskell/comments/4uta1e/proposal_tracking_security_holes_and_major_bugs/

In particular, in contains some examples of real-world bugs that this proposal would track:

https://www.reddit.com/r/haskell/comments/4uta1e/proposal_tracking_security_holes_and_major_bugs/d5sofx9