Where else should we enable this bot?

It's currently installed on cpython and pythondotorg. I suggest we install it also on:

python/pymanager (we'll also have to add it to the CVE_ENABLED list) -- already in policy, just needs install
python/release-tools -- (Add a SECURITY.md with reporting guidelines release-tools#420)
python/blurb_it -- (Add a SECURITY.md with reporting guidelines blurb_it#457)
python/docsbuild-scripts -- (Add a SECURITY.md with reporting guidelines docsbuild-scripts#343)
python/memory.python.org -- (Add a SECURITY.md with reporting guidelines memory.python.org#31)
python/codespeed -- (Add a SECURITY.md with reporting guidelines codespeed#79)
python/pythontestdotnet -- (Add a SECURITY.md with 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?

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 create SECURITY.md for more repositories, too.

@python/organization-owners (sorry for the work, I'd do it myself if I could), please install the psrt-ghsa-bot app 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.md PRs 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.md PRs 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.md to 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.md instead 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 under python org 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.

Let'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 python organisation 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.

@encukou

@encukou, it seems the pymanager repository already has them enabled, can we please install the bot there? CC @zooba

I would like to avoid using an org-global repository with SECURITY.md unless 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.

I 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.

JFTR, I did also open a little PR against our .github, to add the respect and ban notice to the default policy: python/.github#16

it seems the pymanager repository already has them enabled, can we please install the bot there?

~~Also needs the SECURITY.md. I'll get to it after EuroPython.~~

Sorry, somehow I missed it, my bad! pymanager is set up now.

All 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!

Thanks to Stan; I'm just the button-pusher :)

Navigation Menu

Repository navigation

Where else should we enable this bot? #60

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Where else should we enable this bot? #60

Description

Activity

sethmlarson commented on Jul 2, 2026

StanFromIreland commented on Jul 2, 2026

encukou commented on Jul 3, 2026

StanFromIreland commented on Jul 3, 2026

encukou commented on Jul 6, 2026

StanFromIreland commented on Jul 6, 2026

encukou commented on Jul 6, 2026

StanFromIreland commented on Jul 6, 2026

hugovk commented on Jul 6, 2026

StanFromIreland commented on Jul 6, 2026

hugovk commented on Jul 6, 2026

StanFromIreland commented on Jul 6, 2026

encukou commented on Jul 8, 2026

StanFromIreland commented on Jul 8, 2026

sethmlarson commented on Jul 8, 2026

zooba commented on Jul 9, 2026

StanFromIreland commented on Jul 9, 2026

encukou commented on Jul 10, 2026

StanFromIreland commented on Aug 2, 2026

encukou commented on Aug 5, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions