Repository navigation
Where else should we enable this bot? #60
Description
Activity
All of these repositories make sense to me, I think the bot should be enabled for all repositories with GHSA under
python/. We probably want to enable private vulnerability reporting and createSECURITY.mdfor more repositories, too.@python/organization-owners (sorry for the work, I'd do it myself if I could), please install the
psrt-ghsa-botapp for the repositories listed above, and enable private vulnerability reporting (GitHub Security Advisories) for them if they aren't already.I'll take care of the
SECURITY.mds.Can we do the
SECURITY.mdPRs first, to notify the people watching the repos and give them a chance to comment?In that case can we enable private vulnerability reporting first, then do SECURITY.mds, and finally enable the bot?
I was thinking to file
SECURITY.mdPRs first, and do the other two steps at the same time as they're merged.I'm worried about the synchronisation, is it alright if I assign you on the PRs?
Currently, I'm planning to add the following
SECURITY.mdto the above repositories. It is based on CPython's.# Security Policy Python Security Response Team (PSRT) members balance security work against many other responsibilities. Please be thoughtful about the time and attention your report requires. Repeated failure to respect this will result in future reports being rejected, or the reporter being banned from the `python` GitHub organization, regardless of technical merit. ## Reporting a Vulnerability Submit a vulnerability report using GitHub Security Advisories. Reports should be a few sentences describing the vulnerability. Ideally include a proof-of-concept script that reproduces the issue and provides a clear indication of whether the vulnerability is still present. Reports must be plain-text only, including attachments. No PDFs, binaries, notebooks, or other files that cannot be safely reviewed. If your proof-of-concept depends on a specially constructed binary file, please include a script to construct it rather than the file itself. Ideally, include a minimal patch with the mitigation for the report. Reports that do not contain a potential security vulnerability (such as spam or requesting compliance or due-diligence work) will be discarded without a reply.
What does everyone think?
We could make it the global
SECURITY.mdinstead by adding a note e.g., "if enabled submit using GHSA other wise email ..." although I worry it may be a little confusing? That way, it would automatically display on GitHub in all repositories underpythonorg without a policy. It won't show up locally for users, so it's not ideal.is it alright if I assign you on the PRs
Definitely.
We could make it the global SECURITY.md
Let's leave that for later discussion? I don't think the policy applies to e.g. translations.
Reacted by Stan UlbrychLet's leave that for later discussion? I don't think the policy applies to e.g. translations.
It would save many PRs to individual repositories, so let's have a quick discussion before them. While I am leaning towards adding one to each anyway, adding it as the default would be simpler and easier to maintain (one update propagates everywhere automatically). But, it won't technically be a file in the repository, so I'm not convinced. Translations already have the policy (e.g. Polish), all repositories under the
pythonorganisation display it by default, unless over-ridden.Would we want the global one to show up in these repos?
I don't understand Hugo, it already does?
I meant if we update the global org policy to include the text in #60 (comment).
I don't think there will be any particular difference. We'll still point to the email, we'll just suggest reporting via GHSAs if possible. Additionally, it has some nice reporting guidelines (both on how to format the actual report and how to behave :'-( ) which apply everywhere. For most repositories, the policy on python.org is of little relevance.
It would save many PRs to individual repositories
But, IMO, we want PRs. It's good manners to let people know about policy changes on repos they watch/maintain. The discussion needs to be in the affected repo.
Reacted by Stan Ulbrych and Seth LarsonI would like to avoid using an org-global repository with
SECURITY.mdunless it's basically to "catch-all" for projects that are unlikely to be updated. For projects with active contributors we'd want to involve them so there's no surprise about what's happening.Reacted by Steve DowerI also agree with not using the org-global file for "active" subprojects, if only because it's not obvious to maintainers/editors that it's the global one (I nearly rewrote the global one for PyManager a while back ;) ), and because for anything active we should have at least a little bit more information in each about what constitutes a vulnerability for that project.
Reacted by Stan UlbrychJFTR, I did also open a little PR against our
.github, to add the respect and ban notice to the default policy: python/.github#16it seems the pymanager repository already has them enabled, can we please install the bot there?
Also needs theSECURITY.md. I'll get to it after EuroPython.Sorry, somehow I missed it, my bad!
pymanageris set up now.Reacted by Stan UlbrychAll of the repositories have been set up, checking the most recent run which includes:
- python/pythondotorg
- python/docsbuild-scripts
- python/pythontestdotnet
- python/release-tools
- python/cpython
- python/blurb_it
- python/codespeed
- python/pymanager
- python/memory.python.org
Many thanks to Petr for doing all the work!
Reacted by Hugo van Kemenade and Seth LarsonThanks to Stan; I'm just the button-pusher :)
Reacted by Seth Larson
It's currently installed on
cpythonandpythondotorg. I suggest we install it also on:SECURITY.mdwith reporting guidelines release-tools#420)SECURITY.mdwith reporting guidelines blurb_it#457)SECURITY.mdwith reporting guidelines docsbuild-scripts#343)SECURITY.mdwith reporting guidelines memory.python.org#31)SECURITY.mdwith reporting guidelines codespeed#79)SECURITY.mdwith reporting guidelines pythontestdotnet#8)Being able to handle reports there may be useful in the future. Some repositories already have gotten reports (e.g., memory.python.org). What do people think?