feat: add a default security policy #12
Conversation
|
@jan-kiszka @StefanSchroeder Would you also have a look? This serves as a fallback only. Repo-level security policies are preferred. |
There was a problem hiding this comment.
Looks nice and simple @fgreinacher.
As I said i think it might be nice to announce this to projects in https://github.com/siemens?q=&type=source before we merge if they don't have SECURITY.md / .github/SECURITY.md / docs/SECURITY.md, since this will become opt-out immediately after merge IIUC. WDYT? Even something silly like this.
import os
from github import Auth, Github
ISSUE_TITLE = "Default Siemens security policy"
ISSUE_DESCRIPTION = """Dear project maintainers,
The default Siemens organization-wide security poolicy will be applied on xx-xx-xxxx.
If you'd like to opt out, please provide your own [`SECURITY.md` policy](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository).
For more details, see https://github.com/siemens/.github/pull/12."""
auth = Auth.Token(os.getenv("GITHUB_TOKEN"))
gh = Github(auth=auth)
org = gh.get_organization("siemens")
for repo in org.get_repos(type="sources"):
contents = repo.get_content() + repo.get_content("docs") + repo.get_content(".github")
if any([f.path.endswith("SECURITY.md") for f in contents]):
continue
repo.create_issue(title=ISSUE_TITLE, body=ISSUE_DESCRIPTION)(completely untested so might not work at all but you get teh idea 😸)
|
@nejch Great idea with the issue. I'll continue with this after my vacation and we can aim for enabling this in the end of September. |
|
We will also need a way to exclude forks like https://github.com/siemens/linux from this. |
Maybe we can check that with https://github.com/siemens-testing-main to see if it's applied at all to forks, or if there's a way to disable it. (Edit: seems like it is applied, just checked https://github.com/microsoft/openjdk-jdk/security which has no file). Otherwise, worst case scenario maybe we can add a note this does not apply to forks with an explicit list? 🤔 |
|
Forks might be used as PR sources, so I'd really like them to be clean, even "just" visually. |
From what I can see, once we set an org-level So that might be a blocker unless we push local |
|
Hm, that's for sure a blocker. Maybe better to handle that from our internal project, pushing the security policy from there - would also be a bit more explicit and we could notify maintainers there. |
|
I just checked https://github.com/microsoft/openjdk-jdk the only effect is within the About section:
There is the |
|
@bufferoverflow I was looking at this in the security tab: https://github.com/microsoft/openjdk-jdk/security
But true, it's not in the repo, not sure if that's what @jan-kiszka meant. |
|
Yes, but security tab is no problem from my perspective. We could maybe mention within the policy that this is not valid for forks within the organization. |
|
If there is no file visibly sneaked into the forked repo, just the security tab augmented, a statement that this policy does not apply to forks should be enough. |
No, this was never going to be the case :) so this can be solved here in this PR. |
There was a problem hiding this comment.
@nejch @jan-kiszka I added some words regarding the scope of the policy in f4c8f67. PTAL 🙇
So what should we do with the issues in the forks? Just close them? @jan-kiszka, does it make sense to have outdated forks like https://github.com/siemens/linux-ipipe at all? |
@gernot-h we're already discussing this in our community management repo, I'll ping you there so can join the discussion. Regarding issues in forks - we actually filtered out forks on GitHub, but |
|
@fgreinacher should we merge this now? I had a reminder set for this, but we have this in draft still 🙇 |
@nejch Yes, I haven't received any negative feedback. Feel free to do a last pass and merge 🙇 |
|
Thanks @fgreinacher & everyone for your feedback! LGTM. |
No description provided.