PEP 811: Defining Python Security Response Team membership and responsibilities

PEPs
1
Python Enhancement Proposals (PEPs)

PEP 811 – Defining Python Security Response Team membership and...

This PEP proposes formalizing the membership and responsibilities policies of the Python Security Response Team (PSRT). The PSRT is a “highly trusted cabal of Python developers” which handles security vulnerability disclosures to the...

The goal of this PEP is to define the governance of the PSRT such that the membership is managed by the Steering Council, with a policy that balances having many contributors and risk of handling pre-disclosure vulnerability reports. The PEP also defines the process that vulnerability reports will be handled, by creating a role “Coordinator” who is responsible per-report for moving a particular report through PSRT processes within the industry standard 90 day timeline for handling a security report.

Pre-PEP discussion:Pre-PEP: Python Security Response Team Membership and Operations

11 Likes
2

The Python Steering Council may add or remove members and admins of the PSRT. New PSRT members must be core team members, triagers, or PSF staff, and must beproposed to and accepted by the Steering Council.

Is there any need for “must be core team members, triagers, or PSF staff”, given that the SC approval is mandatory? (I’m all about not artificially restricting ourselves through specification - the SC is welcome to have a standing policy of requiring it, but I don’t see why we should need a PEP change to make a reasonable exception.)

On first read I thought it might be for GitHub administration purposes, but if we’re also having apsrt group then that shouldn’t matter?

I’d be happier with something like “New PSRT members must be proposed to SC … and are expected to be drawn from core developers, triagers, or PSF staff.” Which doesn’t rule out the possibility of adding someone else, but makes the expectation pretty clear.

Also, want to put something here about who can propose? Nomination by the existing PSRT members? Self-nomination directly to the SC (probably won’t make the SC happy:wink: )?

10 Likes
3

On first thought, a nomination process similar to core dev since reasonable. Meaning, PSRT members may nominate new members, and existing PSRT members would vote, with 2/3rds positive vote to be included, and given no PSC veto.

1 Like
4

Hmm, it looks like you still have the GHSA platform choice in the PEP:

Using GitHub Security Advisories (GHSA)

This PEP proposes adopting GitHub Security Advisories as the system to accept vulnerability reports due to its tight integration with services already in use by relevant projects.

In the pre-PEP discussion you said:

I can certainly abstract this out so that PSRT is able to choose its tool based on where the projects are hosted and what is available there.

Was this an oversight ?

Should inactive members be more aggressively pruned?

The PSRT only triages a double-digit number of reports every year, meaning there aren’t an abundance of opportunities to “prove” activity on the scale of months. For this reason along with aligning with existing yearly schedules for the Steering Council, a yearly pruning was recommended.

Shouldn’t that last sentence read "For this reason along with aligning with existing yearly schedules for the Steering Council, a yearly pruningis not recommended.

5
steve.dower:

I’d be happier with something like “New PSRT members must be proposed to SC … and are expected to be drawn from core developers, triagers, or PSF staff.” Which doesn’t rule out the possibility of adding someone else, but makes the expectation pretty clear.

Yeah, if the SC is doing filtering then we can change the requirement into a suggestion. This will also simplify the “legacied” PSRT member story, too.

barry:

a nomination process similar to core dev since reasonable. Meaning, PSRT members may nominate new members, and existing PSRT members would vote, with 2/3rds positive vote to be included, and given no PSC veto.

Wecould adopt a process similar to core team nominations. So then the Steering Council would only be able to remove PSRT members with their own vote? I do agree with you and@steve.dower that self-nominations to the SC isn’t appropriate.

malemburg:

I can certainly abstract this out so that PSRT is able to choose its tool based on where the projects are hosted and what is available there.

Was this an oversight ?

There were comments from@gpshead,@JacobCoffee, and@hugovk about keeping the PEP as-is and amending the PEP if we were ever to migrate off GitHub, given if we were to stop using GitHub we’d need to change many other PEPs, too. Hopefully this is okay with you?

malemburg:

The PSRT only triages a double-digit number of reports every year, meaning there aren’t an abundance of opportunities to “prove” activity on the scale of months. For this reason along with aligning with existing yearly schedules for the Steering Council, a yearly pruning was recommended.

Shouldn’t that last sentence read "For this reason along with aligning with existing yearly schedules for the Steering Council, a yearly pruningis not recommended.

The PEP recommends a yearly schedule for pruning (or rather, recommending to the Steering Council candidates to prune), so this sentence is correct. Maybe it can be more clear?

2 Likes
(Barry Warsaw)6
Seth Michael Larson:

Wecould adopt a process similar to core team nominations. So then the Steering Council would only be able to remove PSRT members with their own vote?

Who’s the “their” there, the SC? I think I like the model:

  • PSRT members nominate and vote on new members
  • 2/3rds approval makes it in unless vetoed by the SC
  • A yearly pruning list is given to the SC for approval or amendments
  • SC can explicitly remove people from PSRT if necessary

So generally the PSRT manages its own affairs, with some oversight from the SC.

1 Like
(Marc-André Lemburg)7
Seth Michael Larson:

Hopefully this is okay with you?

Perhaps you could add a comment about this to the PEP.

Seth Michael Larson:

The PEP recommends a yearly schedule for pruning (or rather, recommending to the Steering Council candidates to prune), so this sentence is correct. Maybe it can be more clear?

But then why did you put this under “Rejected Ideas” then ?

(Da Woods)8

My reading was that it was monthly/weekly pruning that was rejected.

3 Likes
9

The main PEP specifies an annual report:

Once per year the Steering Council will receive a report of inactive members of the PSRT with the recommendation to remove the inactive users from the PSRT.

The rejected idea is doing this more often than annually, “on the scale of months”:

Should inactive members be more aggressively pruned?

The PSRT only triages a double-digit number of reports every year, meaning there aren’t an abundance of opportunities to “prove” activity on the scale of months. For this reason along with aligning with existing yearly schedules for the Steering Council, a yearly pruning was recommended.

3 Likes
10

Thanks everyone for weighing in, there didn’t seem to be any disagreement about adopting a similar process to the core team nomination process, so I went forward with that:

github.com/python/peps

PEP 811: Adopt similar nomination process to core team

main ←sethmlarson:pep-811-core-team-approval-process
opened08:07PM - 04 Nov 25 UTC

* Change is either: * [x] To a Draft PEP * [ ] To an Accepted or Final… PEP, with Steering Council approval * [ ] To fix an editorial issue (markup, typo, link, header, etc)* [x] PR title prefixed with PEP number (e.g. ``PEP 123: Summary of changes``)----📚 Documentation preview 📚: https://pep-previews--4686.org.readthedocs.build/

This moves the nomination process to:

  • An existing PSRT member nominates a member.
  • There’s a vote of PSRT members on the nominee, requiring two-thirds positive to pass.
  • The Steering Council will have an opportunity to veto the nomination.

Finally, I added that the Steering Council has the ability to remove members of the PSRT with a simple vote, rather than requiring 4 positive votes to remove a member as is done for the core team. Removing any specifics about PSRT members (core team, triagers, etc) removes the need to define “legacied” members as all (thanks for the suggestion@steve.dower).

5 Likes
11

I’m not on the PSRT so don’t want to hold things up if you’re all in agreement, but you should think twice before adopting such a formal process. A formal vote is stressful, takes time, and requires more effort to take care of the formalities. For CPython, the team is large enough that a formal process makes sense, but I don’t know if that’s true for the PSRT. If possible, I’d stick with what I assume is the current process: the existing members decide using an informal process. If there’s disagreement they can’t resolve, they can escalate to the Steering Council for a decision.

2 Likes
12

As a PSRT member I’m willing to try out the more formal process and see how it goes (I guess that’s part of why I’m a PEP sponsor?:grin:) - if some of us feel it isn’t working we should be willing to speak up with why and propose changing it.

Formalizing the process makes it possible to understandhow to become a member. Up until now it has basically been a “know someone and ask” situation which never feels great.

6 Likes
13

It’ll be interesting to compare this to how a few committees I helped bootstrap a few years ago (Typing Council, Editorial Board and C API Workgroup). Those are less formal. But they are also smaller (5 members each, though that’s not fixed).

14
Seth Michael Larson:

Thanks everyone for weighing in, there didn’t seem to be any disagreement about adopting a similar process to the core team nomination process, so I went forward with that:

PEP 811: Adopt similar nomination process to core team by sethmlarson · Pull Request #4686 · python/peps · GitHub

Steve earlier suggested anyone can join, although with an expectation of where from:

Steve Dower:

I’d be happier with something like “New PSRT members must be proposed to SC … and are expected to be drawn from core developers, triagers, or PSF staff.”

However, thePEP draft still has this which limits the pool:

This PEP proposes limiting PSRT membership only to active coordinators of security vulnerabilities that are core developers or triagers, members involved in oversight (Steering Council), and members who need information about security releases (Release Managers).

Does this need updating?

1 Like
15

Thanks for the reviews, I’ve addressed the comments to make the process similar to the core team nomination process in this pull request which is ready to merge:PEP 811: Adopt similar nomination process to core team by sethmlarson · Pull Request #4686 · python/peps · GitHub

If we’re happy to try out this method (acknowledging that it can always change in the future if it’s really not working), I think the PEP itself is complete with regards to feedback so far in this thread. I’ll leave this thread here for now and if I don’t receive more feedback I’ll start the process of asking the SC for their approval.

Thanks all, have a great weekend.

1 Like
16
Gregory P. Smith:

Formalizing the process makes it possible to understandhow to become a member. Up until now it has basically been a “know someone and ask” situation which never feels great.

To my reading, that’s still the process in the PEP. For example, how would I go about expressing interest in joining?

2 Likes
(Hugo van Kemenade)17
Zachary Ware:
gpshead:

Formalizing the process makes it possible to understandhow to become a member. Up until now it has basically been a “know someone and ask” situation which never feels great.

To my reading, that’s still the process in the PEP. For example, how would I go about expressing interest in joining?

It’s a fairly similar process, but now it’s written down. I didn’t know it was “know someone and ask” before; I became RM, was told I should join and was then added. Now you won’t need to “know someone”, because the list of who to ask is published. And before, it was “know someone and ask, and maybe get added”. Now the selection process is defined.

4 Likes
(Seth Michael Larson)18
zware:
gpshead:

Formalizing the process makes it possible to understandhow to become a member. Up until now it has basically been a “know someone and ask” situation which never feels great.

To my reading, that’s still the process in the PEP. For example, how would I go about expressing interest in joining?

Hugo took the words right out of my mouth, even if the process is mostly the same it’s documented now and the list of people to ask for a nomination is public, so no more awkwardly figuring out who to actually inquire with.

Wanted to also note the enthusiasm, both volunteering and as donated engineering time from an org, about wanting to join seen earlier in the thread and pre-PEP thread if there was a clear process to join the PSRT.

4 Likes
(Seth Michael Larson)19

I’ve submitted this PEP for approval to the SC:https://github.com/python/steering-council/issues/323

Thanks to everyone who contributed to this discussion!

6 Likes
20

Thanks for driving this,@sethmlarson. The SCapproved PEP 811 today.

6 Likes