security release boilerplate

[minrk]

Having made a few security releases (jupyterhub 4.1.6 and 5.1.0 today), it would be helpful to have a template for mentioning patched vulnerabilities in release notes and announcements prior to publishing advisories.

In particular, I find it tricky to decide exactly to mention that there will be an advisory and after how long, and how much to mention about the vulnerability, if anything.

Today, I've gone with:

4.1.6 is a **security release**, fixing [CVE-2024-41942].
All JupyterHub deployments are encouraged to upgrade,
but only those with users having the `admin:users` scope are affected.
The [full advisory][CVE-2024-41942] will be published 7 days after the release.

[CVE-2024-41942]: https://github.com/jupyterhub/jupyterhub/security/advisories/GHSA-9x4q-3gxw-849f

So a template like:

{{ version }} is a **security release**, fixing [{{ cve }}].
All JupyterHub deployments are encouraged to upgrade.
{{ advisory_note }}
The [full advisory][{{ cve }}] will be published 7 days after the release.

[{{ cve }}]: https://github.com/jupyterhub/{{ repo }}/security/advisories/{{ ghsa }}

would be nice to have somewhere.

The part I have the hardest time with is how much to mention about who is affected prior to publication, because:

1. there are lots of different situations, so folks want to know if they are affected
2. the patch is already public in the git history, so to me there is little value in the delayed publication of the advisory

It would also be good to have the release->advisory delay written down somewhere, which I don't think it is.

[betatim]

Is it normal to delay the publication of the advisory? When I think of other projects it is usually the publication of the advisory that makes me notice. Maybe the patch was already released a while before but but because I am not deeply involved in the project I don't notice?

It seems like the important thing to delay, if possible, is a publication of a ready to go exploit before people have time to patch the problem. But I guess often you could construct an exploit without much trouble by looking at the patch. So maybe this is more of a social norms thing than a technical topic?

So maybe the advisory could be published at the same time as the release?

[manics]

I normally publish the advisory when the release is published. If it's easy to exploit it's probably easy for an attacker to find the vulnerability by examining recent commits if they know this includes a security fix even if the details aren't mentioned. I agree we should avoid including example exploit code though in the CVE.

[minrk]

Is it normal to delay the publication of the advisory?

This is also something I want written down! The Jupyter security process docs mention:

Decide on release and announcement dates and post them the draft advisory. These are typically at least a week apart to allow administrators to deploy fixes.

The part I missed and don't understand is:

Make a release to PyPI and/or npm with no announcement or change log

so the delay is to give folks a chance to upgrade without any communication suggesting that they should.

I didn't do this, since I mentioned that there was a vulnerability. I also don't really understand it, because every release without a changelog necessarily becomes a security release, so what does that really accomplish? GitHub private security fork merges are also clearly identifiable in the git history, so it's very easy to see what was a security fix.

Maybe @rpwagner can help with advice on the relationship of publishing fixes and communicating about vulnerabilities?