Automate release publishing

[quarckster]

The current workflow of staging and publishing releases is sub-optimal and involves a lot of manual steps. This issue tracks tasks for replacing steps from these guides:

• https://github.com/openssl/tools/blob/master/HOWTO-make-a-release.md
• https://github.com/openssl/tools/blob/master/HOWTO-publish-a-release.md
• https://github.com/openssl/tools/blob/master/HOWTO-stage-a-release.md

### Tasks
- [ ] https://github.com/openssl/project/issues/855
- [ ] https://github.com/openssl/private/issues/726

[t8m]

IMO we should NOT change the staging process too much, at least until we have the release signing key placed in some kind of HSM. This part of the release is already automated quite well and the manual parts - patch and tarball reviews are necessary and inherently manual. What should be improved/replaced first is the publishing part, IMO.

[quarckster]

until we have the release signing key placed in some kind of HSM

There are options. If we will perform releases in Google Cloud we can use Google Cloud HSM. Another options is to purchase some HSM and use it in our colocation space.

patch and tarball reviews are necessary and inherently manual

Can it be done with the artifacts in the draft release on github? Once all artifacts are reviewed the maintainer can finally publish the release. Draft releases are private by default.

My goal here is to completely get rid off intermediate servers and simplify the release process in three actions.

1. Create a draft release on GitHub
2. Review resulting artifacts
3. Publish the release

[t8m]

The artifacts are not just the tarballs and signatures - the patches need to be reviewed as well. So you at least need to add one more step before your first one. Also please have in mind the security releases with an embargo - they are done slightly differently - from the internal security repo.

[quarckster]

cc @vavroch2010 @nhorman

Please add your comments and tasks to this epic.

[levitte]

Actually, we can kill the use of dev.openssl.org as intermediate right about now. Simply... don't do that step, and like @quarckster says, just create the draft release and upload all artifacts to it instead of to dev.openssl.org. Done.

I think that the one thing that scares us is that the annotated release tag will be exposed, as you simply cannot create a github release without a tag. But quite frankly, the way we've done releases so far, that's what, a 1 hour window for the tag to be "leaked"? That tells me that we worry waaaaay too much.

[quarckster]

cc @nhorman

[quarckster]

As for staging part I propose to initiate it using manual GitHub Actions workflow. Inputs would be a tag name, branch and reviewer. The automation will create a PR and waits until it will be approved by the reviewer. After that it will push commits and the tag to the repository. A GitHub release will be created by another workflow which is trigger on tag push.

[quarckster]

I created a workflow that runs stage-release.sh https://github.com/quarckster/openssl/blob/openssl-3.2/.github/workflows/stage-release.yml. Here is PR which is made by this workflow quarckster/openssl#19. Job logs are here. The workflow looks ugly now. It really should run only one script in one step. I will need to extend stage-release.sh or maybe rewrite some part of it on some mainstream scripting language.

[quarckster]

I created a Jenkins pipeline for staging release. It can create staging PR against github.com/openssl/openssl or github.com/openssl/security.

I tested it in dry run mode to check if all credentials are correct. Here is the testing PR:

• [DRY RUN] 3.5.0-alpha1 release commits openssl#26501