ossf
Help maintainers with answering questions as much as possible
The checklist contains various controls for which either
- I don't know if it's the case (e.g. OSPS-AC-01.01 and OSPS-AC-02.01) where it would be helpful if you could tell me something like "if you're using GitHub you can check this", or
- The language or requirement is ambiguous (e.g. OSPS-DO-01.01) where examples would be helpful to at least get an idea of what is expected, or
- The language is highly security-technical (e.g. OSPS-BR-06.01) where a maintainer might not have the relevant knowledge to answer it (which can lead to either doubtfully leaving it unchecked when it should be checked or over-confidently checking it when it shouldn't be checked).
(more examples, and feedback, in https://github.com/ericcornelissen/shescape/issues/2237#issuecomment-3539079639)
As much as possible, help a maintainer trying to fill out the checklist, at least in the most common case (i.e. probably a project on GitHub). I don't think the current content of https://baseline.openssf.org/maintainers.html is sufficient.
I don't think the current content of https://baseline.openssf.org/maintainers.html is sufficient.
It 100% is not sufficient. It's a work in progress as we try to assemble a more robust suite of examples. If you have examples to add or specific wording improvements, we'd love to have your pull requests. The notes you left in your linked issue are great, though. This is exactly the kind of real-world feedback we need to help make sure we're accomplishing our goals.
It 100% is not sufficient. It's a work in progress as we try to assemble a more robust suite of examples. If you have examples to add or specific wording improvements, we'd love to have your pull requests.
Where would I put examples? I might go over the list and provide some examples where I think it would be helpful.
Regarding wording, I'm not invested enough in this project to spend the time and energy into arguing in favor of wording changes. If you make changes based on what I wrote, feel free to cc me and I'm happy to share my thoughts.
The notes you left in your linked issue are great, though. This is exactly the kind of real-world feedback we need to help make sure we're accomplishing our goals.
Feel free to ask for clarifications in that thread and/or open issues here based on stuff I said there 🙂
Where would I put examples? I might go over the list and provide some examples where I think it would be helpful.
Adding them to this issue is probably fine for now. We need to give some thought to how we will store and present those long-term, but at least having them collected here gets us started.
Some help for answer some questions if your project is on GitHub (covering Level 1 only):
OSPS-AC-03.01: When a direct commit is attempted on the project's primary branch, an enforcement mechanism MUST prevent the change from being applied.
Set up either a ruleset (preferred) or branch protections, in particular you must enable the "Require a pull request before merging" option.
OSPS-AC-03.02: When an attempt is made to delete the project's primary branch, the version control system MUST treat this as a sensitive activity and require explicit confirmation of intent.
Set up either a ruleset (preferred) or branch protections, in particular you must enable "Restrict deletions" for the former or disable "Allow deletions" for the latter.
OSPS-BR-07.01: The project MUST prevent the unintentional storage of unencrypted sensitive data, such as secrets and credentials, in the version control system.
Enable secret scanning.
OSPS-GV-02.01: While active, the project MUST have one or more mechanisms for public discussions about proposed changes and usage obstacles.
This is partially covered by pull requests (which are mandatory for all repositories), but also requires either issues or discussions are enabled.
OSPS-LE-02.01: While active, the license for the source code MUST meet the OSI Open Source Definition or the FSF Free Software Definition. OSPS-LE-02.02: While active, the license for the released software assets MUST meet the OSI Open Source Definition or the FSF Free Software Definition. OSPS-LE-03.01: While active, the license for the source code MUST be maintained in the corresponding repository's LICENSE file, COPYING file, or LICENSE/ directory.
These are satisfied if GitHub shows your selected license by name in the "About" section of your repository's homepage (in the list containing also, e.g., "Activity", "X stars", "Y watching", "Z forks").
OSPS-QA-01.01: While active, the project's source code repository MUST be publicly readable at a static URL.
This is satisfied by the GitHub repository itself, the repository homepage (https://github.com/<owner>/<project>) is such a static URL (assuming your repo is public).