Add silent option

[fcollonval]

This adds the ability to do a silent release; i.e. a release that will have a placeholder in the changelog and that will keep the release in draft mode.

• Add silent option
  • It will set a placeholder in the CHANGELOG file
  • It will save the real changelog in the GH release
  • It will not display the changelog entry in the job log
  • It will keep the release as draft (aka private)
  • It will update the changelog file on publication of the release through a new workflow
• Add workflow to remove the placeholder (I would like to have it execute on release published event to reduce maintenance burden)

---

One question raised by this proposal is that the audience able to see draft release is broader than the one seeing security advisories

[fcollonval]

code is good for review - but I'm testing it against https://github.com/fcollonval/dummy-again to check it works properly

[fcollonval]

From the test repo:

• Prep silent release run: https://github.com/fcollonval/dummy-again/actions/runs/6223832420/job/16890677986

• Publish silent release run: https://github.com/fcollonval/dummy-again/actions/runs/6223859961

• Publish changelog run (triggered when the silent release is published): https://github.com/fcollonval/dummy-again/actions/runs/6224244029

• PR removing the changelog placeholder with the published release body: Automated Changelog Entry - Remove 1 placeholder entries. fcollonval/dummy-again#7

[fcollonval]

I updated the documentation

The current documentation is not compatible with the second comment of removing the new parameter from the example workflow. Happy to get suggestion on how to mention the new parameter in the documentation if it is not part of the example worflow.

[Carreau]

I have no objections to this, but IIUC to do the release the GH-advisories need to be merged and are public anyway, am I misunderstanding ?

If that's the case I don't think hiding the changelog is going to change things much.

Also one thing it is always save to publish is CVE-number. It is ok to publish them before the CVE/patches are public as it allows users to track wether they might be vulnerable or will need to upgrade once a patch is published.

[Carreau]

From the test repo:

• Prep silent release run: https://github.com/fcollonval/dummy-again/actions/runs/6223832420/job/16890677986
• Publish silent release run: https://github.com/fcollonval/dummy-again/actions/runs/6223859961
• Publish changelog run (triggered when the silent release is published): https://github.com/fcollonval/dummy-again/actions/runs/6224244029

Those have (Optional): Review Draft Release: https://github.com/fcollonval/dummy-again/releases/tag/untagged-ead39ca0a2de524e44cc and those gives 404 to me, so it's likely they are private.

[jtpio]

I have no objections to this, but IIUC to do the release the GH-advisories need to be merged and are public anyway, am I misunderstanding ?

That was also my initial understanding but thought the process had changed in the meantime.

[fcollonval]

I have no objections to this, but IIUC to do the release the GH-advisories need to be merged and are public anyway, am I misunderstanding ?

This is a good point that I cannot answer. @blink1073 would you mind sharing your experience on that?

[krassowski]

Those have (Optional): Review Draft Release: https://github.com/fcollonval/dummy-again/releases/tag/untagged-ead39ca0a2de524e44cc and those gives 404 to me, so it's likely they are private.

Drafts are only visible to repo/organization maintainers, but I think that logs are visible to all logged in users:

[krassowski]

I have no objections to this, but IIUC to do the release the GH-advisories need to be merged and are public anyway, am I misunderstanding ?

From reading GitHub docs, I do not believe that this is the case; they imply that you can merge the pull request from private fork without making the advisory public. Also, you need to provide information on versions affected and version fixed to publish advisory (which you can fake before making the actual release).

I think that ideal the order is:

1. populate affected versions in advisory
2. request CVE
3. merge/backport
4. release to npm/pypi/conda
5. populate "patched versions" in advisory
6. publish advisory
7. publish changelog (/GitHub release) with link to advisory

This is what the GitHub docs says https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability:

After you merge changes in a security advisory, you can publish the security advisory to alert your community about the security vulnerability in previous versions of your project. For more information, see "Publishing a repository security advisory."

And the fragment which explains that the "patched version" should be populated: https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/publishing-a-repository-security-advisory#about-publishing-a-security-advisory

Warning: Whenever possible, you should always add a fix version to a security advisory prior to publishing the advisory. If you don't, the advisory will be published without a fixed version, and Dependabot will alert your users about the issue, without offering any safe version to update to.

We recommend you take the following steps in these different situations:

• If a fix version is imminently available, and you are able to, wait to disclose the issue when the fix is ready.
• If a fix version is in development but not yet available, mention this in the advisory, and edit the advisory later, after publication.
• If you are not planning to fix the issue, be clear about it in the advisory so that your users don't contact you to ask when a fix will be made. In this case, it is helpful to include steps users can take to mitigate the issue.

[krassowski]

The silent option comes in handy because between merging and backporting there can be a delay of between minutes to hours if something goes wrong (and we had recent experience where GitHub outages would delay the release pipeline by several hours). IMO, whether it is worth a hassle depends on how high severity are the vulnerabilities.

[blink1073]

I agree with @krassowski's assessment

[blink1073]

See also #333

[fcollonval]

18471a4 hide the new changelog entry in the job log if the silent option is checked.

[fcollonval]

@jtpio @krassowski I would like to move forward with this one. There is a hanging question about the example workflow. What are your opinions on that?

[fcollonval]

Hey @blink1073 would you mind reviewing this PR?

[blink1073]

Yep, I reviewed half the files today, will finish tomorrow.

[blink1073]

LGTM, thank you!

[fcollonval]

Thanks @blink1073 for the review