Seeking advice from the security council on PR

[fcollonval]

At JupyterLab weekly call, we discussed the PR adding a silent option to the releaser (to publish security release mainly). We would like some members of the security council to look at it and to provide some advice on the process:

jupyter-server/jupyter_releaser#526

For now, if the silent option is set, the changelog file in the repository will be updated with a placeholder instead of the list of changes and the GitHub release will stay in draft mode (with the real changelog to be included in the changelog when made public).

To limit the changelog visibility, that PR should be updated to remove the changelog from the CI job logs. But there will be still a higher visibility of the draft release compare to the advisories.

[Carreau]

In my opinion once a released is publish and some information is available somewhere it does not matter much to hide informations or not. An attacker will find it and find it fast, as it's easy to compare with previous releases and find the patch/flaw anyway.

I am of the impression that's it's better to have explicit release with "this fix CVE-XXXX" "The conditions of vulnerability are XYZ", and you can mitigate with "mitigating instructions".

The benefits for users/downstream will outweight the risk of an attacker gaining a few hours of reverse engineering.

[rpwagner]

@fcollonval here's my understanding of the discussion in jupyter-server/jupyter_releaser/pull/526.

First, the priority is to ensure that an updated version of the code correcting a vulnerability is release before the security advisory for the vulnerability is published. That makes sense and avoids Dependabot alerts that can't be corrected.

Second, you're asking about what to do with the changelog during the silent release. I don't think it's worth removing it for the silent release. Just include a line like @Carreau says "Corrects CVE-XXX". Once the full CVE is published, then they can see the details of the fix. Messing with the changelog just seems like too much work and may unintentionally remove information from downstream users and package maintainers.