Documenting security mailing list (and restarting it to avoid spam filters?)

[krassowski]

A recent blog post described two mailing lists relating to security:

We have 2 mailing list for security-related discussion. The first one – [email protected] – has only a couple of members all core contributors and can receive email from the outside, it is used for triage. It receive a high number of spam as this is public email. As it has only a few members and we are all busy, mail can slip through. The second mailing list is slightly larger, and used for internal announcement for stakeholder. It has a fairly open membership model, (ask a Jupyter developer if you can be on it, and the reason why and we’ll likely add you), though it’s content seem to be ignored (it even lands on my spam folder, not sure why).

It could help to clarify how to sign up for the second (more open) mailing list and what are the vetting criteria for the membership. As for signing up, the number of Jupyter contributors across all the projects is not small and not everyone will be already on the list/have rights to add others (and the term Jupyter developer is not well defined for me either) so clarifying who can add new members and which communication channel to use (gitter? discourse? email?) would help a lot. I imagine that the new security page, or the README of this repo (or both) would be a good place to host this information.

The documentation should mention that once added the new members will receive a message from "Jupyter Security" confirming their subscription (and they can unsubscribe at any time), which may land in spam (but no confirmation is required). We could also note that the membership is visible to other members.

Speaking of spam, would it make sense to re-start the mailing list from scratch using a different address so that the emails are not flagged as spam? I think it currently uses an ipython-based address and we could probably have one with jupyter instead.

[Carreau]

It could help to clarify how to sign up for the second (more open) mailing list and what are the vetting criteria for the membership.

There is no particular vetting, not particular communication channel, it's mostly to not have automatic scraping, and make sure that we don't get random mails or people who don't understand what the mailinglist is for. We get a lot of spam on [email protected], from marketing, SEO, and anything that crawl the web.

List of the ipython-security google group members that are owner:

• me, Fernando, Brian, Carol, Damián, Jason, Jessica H, Kyle, M, Min, Nick, Paul, Peter, Thomas.
  (no objections from to to add/remove people that are owner)

I'm open to any changes to the communication channels, and formalisation.

Speaking of spam, would it make sense to re-start the mailing list from scratch using a different address so that the emails are not flagged as spam? I think it currently uses an ipython-based address and we could probably have one with jupyter instead.

I would avoid @jupyter.org as well, it's not better maintained than IPython.org, this was one of the reason tha made me propose [email protected] in #7

[krassowski]

Recently when spreading awareness about an advisory in jupyyter-server call I was asked whether I shared an advisory on the external mailing list ([email protected]) by @Zsailer. I did not. We acknowledged that the list did not seem to be used regularly - in last year there were only two announcements posted (both in May be Steve), although over a dozen of advisories were published (including on JupyterHub, JupyterLab, and in various other repositories).

I think I found myself confused when Zach pointed out that the vulnerability handling process documentation includes a mention of sending an email to a list:

security/docs/vulnerability-handling.md

Lines 73 to 74 in 36b5b3d

	- **Coordinator**: Post the release and announcement dates on the Jupyter Security [Mailing List]([[email protected]](mailto:[email protected]))
	- **Developer**: Merge the security fix PR

However upon a second look I see that this refers to [email protected], not the google group mailing list. I never sent an email to coordinate the way as described in the handling process guide but instead I was always tagging individual security group members (if already engaged in the conversation) or the security managers group (otherwise) to give a heads up on the release and I think this was a running practice for all the vulnerability handling processes that I witnessed (but I cannot say for sure as if someone else did send an email to [email protected] in the background I would not have known).

A couple of action items I would propose:

• link the vulnerability handling docucment in SECURITY.md in all orgs - I forgot that this document exists and I know that many maintainers either forgot about it too or never knew about it
• update the vulnerability handling document to clarify whether tagging security managers is sufficient or not to announce intent to release a vulnerability advisory (or whether sending an email is required)
• update the vulnerability handling document to mention the second mailing list and clarify when to send an announcement to it, how should do that and how to do that
• describe where to sign up to this list and formalize it somewhere in the docs; maybe advertise it to companies funding Jupyter via LF
• maybe formalize that owners of the list should be EC or SSC members and set up a GitHub bot opening an issue once a year asking to update the list

For context, citing the only source of information about the mailing list I know from the official blog post linked about:

The second mailing list is slightly larger, and used for internal announcement for stakeholder. It has a fairly open membership model, (ask a Jupyter developer if you can be on it, and the reason why and we’ll likely add you), though it’s content seem to be ignored (it even lands on my spam folder, not sure why).

[krassowski]

I can work on the above but I will wait on some kind of blessing from the security subproject/EC before starting anything.

[fperez]

Huge thanks @krassowski @Carreau for working on this, and thanks Mike for coming today to discuss at EC Office Hours. This comment is mostly to signal that we had a long, good discussion with Mike about all the above. Mike can follow up later with concrete steps, but we (the EC members in the call today) are largely in agreement, and we mostly want to emphasize that our role is to support the various teams in the project, not to block them :)

Ultimately organizing our security related information so the main public page is as complete, up to date and consistent as possible is a great goal, and we support the idea that various other documents (like this not so easy to find one about vulnerability handling) should be consolidated and more discoverable.

The one thing to probably wait a little bit on is potentially changing the emails used for reporting and announcements - having them be about 'ipython' (in the name or the domain) is a historical artifact and not very useful. In the long run we want all that to point to jupyter, but we're right in the middle of the transition to LF infrastructure. So let's wait a little bit on making changes to those addresses. Other updates, though, such as clearer messaging on the function of these distinct channels (inbox for reporting vulnerabilities with very limited read access vs. discussion/announcements mailing list with open access) can be made now, and we'll just wait a little to update their addresses.

Thanks again Mike for the time today and your ongoing work, as well as @Carreau and the rest of the security team!