docs(rfc): add private repository access control#36
Conversation
Propose that private repositories in ODP follow a strict least-privilege model where organization membership alone does not grant visibility. Access must be explicitly granted through approved teams or direct repository permissions.
There was a problem hiding this comment.
Pull request overview
Adds an RFC proposing a least-privilege access model for private repositories in the Open Device Partnership (ODP), where organization membership alone does not grant visibility/access and access must be explicitly granted via teams or direct repo permissions.
Changes:
- Introduces a new RFC defining “default deny” private repo access requirements and exceptions.
- Documents goals, requirements, alternatives, rollout/adoption strategy, and open questions for review.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| 1. Should there be a small number of standing exception teams (for example, security or release administration), and if so, how are those exceptions governed? | ||
| 2. What evidence should repository owners retain to show six-month access recertification was completed? | ||
| 3. Should direct collaborator grants on private repositories require additional justification or expiration? | ||
| 4. Should ODP also define guidance for when work should move from private to public? |
There was a problem hiding this comment.
One-size-fits all guidance might be tough, but maybe our guidance should be something along the lines of "private repos should only be created with the intention of going public in the future".
I think we should make it clear the ODP org isn't a place to host repos that are intended to stay permanently private/closed to the wider community and if a partner has need for that, it's up to them to host that repo on their own.
There was a problem hiding this comment.
That is a good point. That is our intent. I will incorporate that into the document.
There was a problem hiding this comment.
Thinking about this a bit, this might be too strong a stance. For partner that does not have a GH org, if they want to share some code with us on ODP for collaboration that has their IP that is not intended to be ever released to the public, we should respect that. I do agree in principle, in general any ODP platform or framework related item should be intended to be public or be contribute back to a public repo in the future.
There was a problem hiding this comment.
I agree that going public should be the primary use case and you could call out that exception.
|
|
||
| The following questions should be resolved during RFC review: | ||
|
|
||
| 1. Should there be a small number of standing exception teams (for example, security or release administration), and if so, how are those exceptions governed? |
There was a problem hiding this comment.
Do you have specific teams in mind now?
There was a problem hiding this comment.
Org admins will always have full visibility. cargo vet auditor team might need to have some visibility but if it is private.
| The following questions should be resolved during RFC review: | ||
|
|
||
| 1. Should there be a small number of standing exception teams (for example, security or release administration), and if so, how are those exceptions governed? | ||
| 2. What evidence should repository owners retain to show six-month access recertification was completed? |
There was a problem hiding this comment.
I think it is important to have explicit acknowledgement an audit was performed. Maybe an automated email that requires an affirmative reply?
There was a problem hiding this comment.
Automated email would be a good reminder, but I think we need to have some records of audits that is permanent as well. Maybe some kind of document for access audit and then a github workflow that triggers every 6 months for private repos to audit access list.
As org, we need an org-wide audit as well.
There was a problem hiding this comment.
I like the idea of a permanent record, and I understand it can't be in this repo because it is public and these repos are not. However, this might need to be defined a bit more formally (like either a private centralized repo that holds audits or a consistent process/workflow that can be applied to each repo).
For now, I think what you have is fine. But perhaps you could leave a note in the unresolved questions section or somewhere to follow up on repeatable process?
- Explicitly state org admins retain full visibility - Require team-based access by default (no individual grants without justification) - Rename Requirement 5 to '6-month access audit' for visibility - Add Requirement 6 for audit evidence and record-keeping - Add Requirement 9 requiring upstream contribution of ODP platform/framework code - Add private-to-public transition checklist in Adoption Strategy - Update Unresolved Questions with resolved/open subheadings - Add open question on partner IP repo retention period
Propose that private repositories in ODP follow a strict least-privilege model where organization membership alone does not grant visibility. Access must be explicitly granted through approved teams or direct repository permissions.