Recommends mechanisms to distribute secrets, provides an example implementation, and lists suitable hosted services. For more details see:
Just following up from my comments on the NumPy mailing list. In principle it doesn’t sound very onerous to have yearly check-ins, but in practice (I’ve had this happen) if check-in emails are missed even active maintainers can be locked out.
On the other hand, this spec is focused on security, and maybe I’m inferring too much by seeing it as a proxy for establishing an active / inactive maintainer status (at least with respect to secrets / tokens).
I’d be happy to support this without the line about reviewing active membership / or if it was made clearer that this need not be a separate opt-in system (e.g. even if you are a regular contributor to each release; forgetting to respond to a query about reviewing secrets access should not immediately cause loss of access).
Thanks for posting your concern, Rohit. I think what I had in mind with “review permissions” was that someone would look at the permissions and ask the question “should this person still have permissions”. If the person is no longer involved in the project, then no. If they’re an active maintainer (whether or not they’ve been seen in the last month), probably yes.
Here’s the sentence from the SPEC:
Review permissions regularly (say, every year) to maintain minimal permissions.
I don’t think the SPEC is (or should be) prescriptive about how a project determines whether permissions are kept. Do you have a suggestion on how to make that clear?
I reviewed skimage’s permissions recently, and found that we had people with admin rights who had left the projects years ago! We do review our team membership once a year or so, but that’s a separate matter.
2 Likes