Communicating security-related issues/topics to Jupyter developers

[rcthomas]

At today's Jupyter community call @sgibson91 mentioned the recent Travis CI issue and whether we had a process for alerting Jupyter developers about those kinds of vulnerabilities. What are the best processes/procedures for getting the word out? We've got, or could use:

• Discourse (but are security posts visible enough there, and not everyone looks at it)
• Email lists (probably not a lot of excitememt about a new one)
• The Jupyter blog has been used to make statements about security
• Some way to identify Jupyter projects on GitHub and automatically open issues on them (?)

Other ideas?

[Carreau]

• We also tweet out when we publish a blog post, or something similar.
• Dependabot will suggest update when a new version is published.

a suggestion suggestion would be to also have a list of CVE on a given page on Jupyter.org (and rss feeds?).

Im wondering if there is a way to get notified for changes to the github advisory database. Like set a query: https://github.com/advisories?query=jupyter and recieve email when a new entry matches.

[rpwagner]

@Carreau I'd like to document the current processes for vulnerability handling. Do you think this is something we could capture during one of the security calls? From there maybe we take it to the Steering Council as a JEP and later refinement.

[Carreau]

I'd like to document the current processes for vulnerability handling. Do you think this is something we could capture during one of the security calls? From there maybe we take it to the Steering Council as a JEP and later refinement.

Yes we can try to capture that, one of the problem is that there is no real process. It's anyone that has access to security@ipython.org does their best.

[blink1073]

Here's a sketch of what we've been doing in practice:

• Open a draft GitHub Security Advisory
  • Include relevant but sanitized details in the top level comment, which becomes public
  • Sensitive details and reproductions go in the comments on the draft advisory, which are not public
  • Add relevant people to the advisory - note we need an official list of GitHub handles here since teams don't work across orgs
  • Request a CVE from GitHub. This is private until the advisory is published.
  • Work on the vulnerability fix PR
  • Once the fix is agreed upon, wait for the CVE number to be issued.
  • Decide on release and announcement date sand post them the draft advisory. These are typically at least a week apart to allow administrators to deploy fixes.
• Post the release and announcement dates on the Jupyter Security Mailing List
• Merge the security fix PR
• Make a release to PyPI and/or npm with no announcement or change log
• Publish the security advisory on the announcement date. GitHub will post the CVE to the MITRE database

What we haven't yet established is where else to announce these vulnerabilities.

[blink1073]

@jweill-aws I've updated the comment above as per our discussion today in the server meeting.