Disambiguating version control system and repository

[adityasaky]

In OSPS-01:

The project's version control system MUST require multi-factor authentication for collaborators modifying the project repository settings or accessing sensitive data.

The definition for VCS points to examples like Git that cannot enforce multi-factor authentication. The definition for "repository" is closer to a source control platform (SCP) such as GitHub or GitLab that can enforce multi-factor authentication. I'm unsure if just replacing VCS with repository is sufficient, especially since the word "repository" doesn't always mean the centrally hosted copy to everyone.

Separately, does this requirement exclude other options for hosting source code? For example, I'm unsure if https://git.kernel.org/ can meet the MFA requirement.

[eddie-knight]

The definition for "repository" is closer to a source control platform (SCP) such as GitHub or GitLab

Agree with the problem statement here. I'm not finding any cases of "source control platform (SCP)" used in the wild. That's not inherently a problem, but as alternatives we might also consider something like "VCS platform" or "version control platform."

does this requirement exclude other options for hosting source code?

This has been a point of contention for us on other entries as well. The current stance is that if a project or tool doesn't meet the baseline, it's their prerogative to either explain the reasoning to their users, or add features to conform as needed. (We shouldn't lower the bar simply because someone isn't currently passing it.)

[adityasaky]

This has been a point of contention for us on other entries as well. The current stance is that if a project or tool doesn't meet the baseline, it's their prerogative to either explain the reasoning to their users, or add features to conform as needed. (We shouldn't lower the bar simply because someone isn't currently passing it.)

Overall, I agree with not lowering the bar because someone isn't currently passing it. But I think there's a question of applicability here which goes back to the definitions and desired properties for the control. Perhaps we first have to establish whether git.kernel.org even fits the SCP / VCS platform definition? It's possible it doesn't.

"Require multi-factor authentication for the project's version control system, requiring collaborators to provide a second form of authentication when accessing sensitive data or modifying repository settings." I parse this to mean git.kernel.org doesn't meet the definition, but at first read it would seem that the control does apply and the project doesn't meet it. Maybe the controls could emphasize the objective more and indicate that MFA is one way to meet the objective for SCPs like GitHub?

[david-a-wheeler]

The current stance is that if a project or tool doesn't meet the baseline, it's their prerogative to either explain the reasoning to their users, or add features to conform as needed. (We shouldn't lower the bar simply because someone isn't currently passing it.)

You're talking about what the final baseline should aspire to be. However, we must be careful that the baseline doesn't accidentally require "one true way" to meet a security requirement. For example, in some cases the baseline presumes that only centralized VCS exists, but git was designed to support decentralized VCS. It's really easy for "requirements" to really just require implementation details. We should try to make the requirements the actual requirements. I'll try to suggest something to help; it's hard to do!