jupyter / security

BSD 3-Clause "New" or "Revised" License
19 stars 7 forks source link

Move/Extend security subproject to the numfocus level. #6

Open Carreau opened 3 years ago

Carreau commented 3 years ago

This conversation was started a bit on the meeting 8 days ago.

It appear to me that beyond the scope of Securing Jupyter, there are security aspect that could be tackled at the NumFOCUS level.

Indeed, security in a Jupyter environment is not limited to how Jupyter is deployed, but can also be affected by all the packages installed. And if to the core contributors it might be obvious who to contact and which projects are impacted, questions about security or vulnerability disclosure, the point of contact might be unclear.

In practice, there is also monitoring and configuration issue at the Jupyter Level where security(at)ipython.org, mails can go to spam, be ignored, or bounce. And the key management is imperfect.

I would like to suggest the following to the NumFOCUS board:

To be clear I don't expect people from this committee to decide the best practices about security, or work on fixing the security issue, but to make sure security that there is a single unified point of contact across the PyData ecosystem, and a guaranteed fast acknowledgement of reports.

If we want an actual proposal to numfocus then we need a better document that list exactly what we are asking for, and who would serve on this committee.

Carreau commented 3 years ago

cc @SylvainCorlay

Carreau commented 3 years ago

See #7 for a draft.

choldgraf commented 3 years ago

I think this could be a nice pooling of resources across the community. I'd bet that many security vulnerabilities would be relevant to the stakeholders across many projects, and in addition I suspect that things like "watch the security email listserv" is a thankless job that is hard to do equitably with limited resources. For that reason, finding ways to pool resources across NumFocus projects could be helpful.

A few things that I think should be included in a suggestion:

Carreau commented 3 years ago
  • Explicit expectations of the people in this group, so they understand the scope of their responsibilities

Yes, that is in #7,

  • Explicit mechanisms for this group to escalate legitimate problems to others, otherwise this group may feel the tension that comes with being responsible for "triaging" issues without being empowered/able to actually fix them

So far in #7 to keep things simple, I assume that reports are acted upon, and if not this group can report the board of director of Numfocus. My expectation is that people care and the the community is small enough with NF holding contact info that anybody can be reached. I hope to extend that later if the groups originally work.

  • Term limits for people serving on this group, so that this labor is spread across people from the community (or at least, other ways to incentivize people to want to serve in this group)

That's a good thing to add thanks, I also receive the default charter for NF from leah and will adapt #7 to it. Main question so far is can we find 5 people ok with serving on it in a first pass.

rcthomas commented 3 years ago

@Carreau I've been unable to review the PR due to time constraints but hope to take a look and give feedback in the next several days.

Carreau commented 3 years ago

I've been unable to review the PR due to time constraints but hope to take a look and give feedback in the next several days.

No worries, I've also received the NF official charter, so I might need to adapt it to it. It's really a draft, and I guess the harder would be to find 5 people to start.