(the source repo being one of `git@github.openssl.org:openssl/openssl.git`
or `git@github.openssl.org:openssl/premium.git`)
-### OpenSSL 3.0 and on
-
The release generating script is in the OpenSSL source checkout, and is
generally called like this:
- dev/release.sh --reviewer=NAME
+ $TOOLS/release-tools/release.sh --reviewer=NAME
This script has a multitude of other options that are useful for specific
cases, and is also self-documented:
- To get a quick usage reminder:
- dev/release.sh --help
+ $TOOLS/release-tools/release.sh --help
- To get a man-page:
- dev/release.sh --manual
-
-### OpenSSL before 3.0
-
-The release generating script is in the tools checkout, represented here
-with $TOOLS, and is generally called like this:
-
- $TOOLS/release-tools/mkrelease.pl --reviewer=NAME
-
-The manual for that script is found in `$TOOLS/release-tools/MKRELEASE.md`
+ $TOOLS/release-tools/release.sh --manual
## Update the release data locally
Check that the release has been uploaded properly. The release tarballs and
associated files should be in ~openssl/dist/new. They should be owned by
-the openssl userid and world-readable.
+the "upload" userid and world-readable.
Copy the tarballs to appropriate directories. This can be done using the
do-release.pl script. See $TOOLS/release-tools/DO-RELEASE.md for a
ls /srv/premium
*For OpenSSL 3.0 and on*, push your local changes to the appropriate source
-repo as instructed by `dev/release.sh`. You may want to sanity check the
-pushes by inserting the `-n` (dry-run) option.
+repo as instructed by `$TOOLS/release-tools/release.sh`. You may want to
+sanity check the pushes by inserting the `-n` (dry-run) option.
*For OpenSSL before 3.0*, simply push your local changes to the appropriate
source repo, and please do remember to push the release tags as well. You
git push <repository> <tagname>
+Upload the release files to the "Releases" section on github. Visit this URL:
+
+https://github.com/openssl/openssl/releases
+
+Click the "Draft a new release" button. Give the release a title, e.g.
+"OpenSSL 3.1.0". Give it a description. Typically this will be the same text
+that was used in the newsflash.txt file to announce the release. Upload the
+four release files, e.g.
+
+openssl-3.1.0.tar.gz
+openssl-3.1.0.tar.gz.asc
+openssl-3.1.0.tar.gz.sha1
+openssl-3.1.0.tar.gz.sha256
+
+If this is not the latest stable release, uncheck the "Set as the latest release"
+checkbox. If this is an alpha or beta release check the "Set as a pre-release"
+checkbox. Finally click "Publish release".
+
## Updating the release data
If there is a PR against the release repo to be merged, perform the merge
To finish, log in on dev.openssl.org and send the signed Security
Advisory by email as the user that signed the advisory.
-For all releases, send them to the default set of public mailing lists:
+For all releases, send it to the default set of public mailing lists:
REPLYTO="openssl@openssl.org" mutt -s "OpenSSL Security Advisory" \
openssl-project openssl-users openssl-announce \
+ </tmp/secadv_FILENAME.txt.asc
+
+We also send it separately to oss-security (to avoid cross-posting with our
+own lists):
+
+ REPLYTO="openssl@openssl.org" mutt -s "OpenSSL Security Advisory" \
oss-security@lists.openwall.com \
</tmp/secadv_FILENAME.txt.asc
-For premium releases, send them to support-announce as well *and
-separately*:
+Finally we also, send it to support-announce as well *and separately*. We always
+do this, even if a premium release has not been affected:
REPLYTO="openssl@openssl.org" mutt -s "OpenSSL Security Advisory" \
support-announce </tmp/secadv_FILENAME.txt.asc