- [SSH access](#check-your-access)
- [A method for reviewing](#a-way-to-reviewing)
- [Pre-publishing tasks](#pre-publishing-tasks)
- - [Freeze the source repository](#freeze-the-source-repository) [the day before release]
- [Prepare your repository checkouts](#prepare-your-repository-checkouts)
+ - [Freeze the source repository](#freeze-the-source-repository) [three business days before release]
- [Make sure that the openssl source is up to date](#make-sure-that-the-openssl-source-is-up-to-date)
- [Generate the tarball and announcement text](#generating-the-tarball-and-announcement-text)
- [OpenSSL 3.0 and on](#openssl-3.0-and-on)
- [OpenSSL before 3.0](#openssl-before-3.0)
- - [Update the website locally](#update-the-website-locally) [do not push]
+ - [Update the release data locally](#update-the-release-data-locally)
+ [do not push]
- [Publish the release](#publish-the-release)
+ - [Updating the release data](#updating-the-release-data)
- [Post-publishing tasks](#post-publishing-tasks)
- - [Check the website](#check-the-website)
+ - [Check the website](#check-the-website) [only for public releases]
- [Send the announcement mail](#send-the-announcement-mail)
- [Send out the Security Advisory](#send-out-the-security-advisory)
- [Unfreeze the source repository](#unfreeze-the-source-repository)
You must have access to the following repositories:
-- `openssl-git@git.openssl.org:openssl.git`
+- `git@github.openssl.org:openssl/openssl.git` or
+ `git@github.openssl.org:openssl/premium.git`
- This is the usual main source repository
+ `openssl/openssl` is the public source repository, while
+ `openssl/premium` is the premium release repository.
-- `openssl-git@git.openssl.org:openssl-web.git`
+- `git@github.openssl.org:otc/tools.git`
- This is the website repository
+ This contains certain common tools
-- `openssl-git@git.openssl.org:tools.git`
+- `git@github.openssl.org:omc/data.git`
- This contains certain common tools
+ This contains files to be updated as part of any release
## PGP / GnuPG key
Some of the actions in this section need to be repeated for each OpenSSL
version released.
-## Freeze the source repository
-
-The day before the release, freeze the main repository. This locks out
-everyone but the named user, who is doing the release, from doing any
-pushes. Someone other than the person doing the release should run the
-command. For example:
-
- ssh openssl-git@git.openssl.org freeze openssl NAME
-
## Prepare your repository checkouts
You will need to checkout at least three working trees:
-- one for the website
-
- git clone openssl-git@git.openssl.org:openssl-web.git website
-
- one for extra tools
- git clone openssl-git@git.openssl.org:tools.git tools
+ git clone git@github.openssl.org:otc/tools.git tools
The resulting directory will be referred to as `$TOOLS`
+- one for release data
+
+ git clone git@github.openssl.org:omc/data.git data
+
- At least one for openssl source
- git clone openssl-git@git.openssl.org:openssl.git
+ git clone git@github.openssl.org:openssl/openssl.git
+
+ or
+
+ git clone git@github.openssl.org:openssl/premium.git
If you're doing multiple releases in one go, there are many ways to deal
with it. One possibility, available since git 2.5, is to use `git
(cd openssl;
git worktree add ../openssl-1.1.1 OpenSSL_1_1_1-stable)
+## Freeze the source repository
+
+Three business day before the release, freeze the appropriate source
+repository.
+
+This locks out everyone but the named user, who is doing the release, from
+doing any pushes. Someone other than the person doing the release should
+run the command.
+
+This must be done from a checkout of that source repository, so for public
+releases:
+
+ git push git@github.openssl.org:openssl/openssl.git HEAD:refs/frozen/NAME
+
+and for premium releases:
+
+ git push git@github.openssl.org:openssl/premium.git HEAD:refs/frozen/NAME
+
+Where `NAME` is the github username of the user doing the release.
+
+Note: it currently doesn't matter what source branch is used when pushing,
+the whole repository is frozen either way. The example above uses whatever
+branch you happen to have checked out.
+
## Make sure that the openssl source is up to date
The person doing the release and the reviewer should both sanity-check the
$TOOLS/release-tools/do-copyright-year
-Obtain approval for these commits from the reviewer and add the reviewed-by
-headers as required.
+Obtain approval for these commits from the reviewer and add the Release and
+Reviewed-By trailers as required.
*Do* send the auto-generated commits to the reviewer and await their
approval.
-*Do not push* changes to the main source repo at this stage.
-(the main source repo being `openssl-git@git.openssl.org:openssl.git`)
+*Do not push* changes to the source repo at this stage.
+(the source repo being one of `git@github.openssl.org:openssl/openssl.git`
+or `git@github.openssl.org:openssl/premium.git`)
## Generate the tarball and announcement text
*Do* send the auto-generated commits to the reviewer and await their
approval.
-*Do not push* changes to the main source repo at this stage.
-(the main source repo being `openssl-git@git.openssl.org:openssl.git`)
+*Do not push* changes to the source repo at this stage.
+(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 manual for that script is found in `$TOOLS/release-tools/MKRELEASE.md`
-## Update the website locally
+## Update the release data locally
-*The changes in this section should be made in your clone of the openssl
-web repo*
+*The changes in this section should be made in your clone of the release
+data repo*
+
+- Newsflash *[only for public releases]*
+
+ Update the newsflash.txt file. This normally is one or two lines. Just
+ copy and paste existing announcements making minor changes for the date
+ and version number as necessary. If there is an advisory then ensure
+ you include a link to it.
-Update the news/newsflash.txt file. This normally is one or two lines.
-Just copy and paste existing announcements making minor changes for the date
-and version number as necessary. If there is an advisory then ensure you
-include a link to it.
+- Security advisory *[both public and premium releases]*
-Update the news/vulnerabilities.xml file if appropriate.
+ Update the vulnerabilities.xml file if appropriate.
-If there is a Security Advisory then copy it into the news/secadv directory.
+ If there is a Security Advisory then copy it into the secadv directory.
-*Do* send the commits to the reviewer and await their approval.
+Make a pull request from your changes, against the release data repo (the
+release data repo being `git@github.openssl.org:omc/data.git`).
-Commit your changes, but *do not push* them to the website repo at this stage.
-(the website repo being `openssl-git@git.openssl.org:openssl-web.git`)
+*Do not merge the pull request at this point*, even if the reviewer already
+approved it.
+
+*Do* send the commits to the reviewer and await their approval. It's
+advisable to use this command to get a copy of those commits:
+
+ git format-patch
# Publish the release
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
send the announcement emails later. Keep a note of those commands for
future reference.
-Verify that the tarballs are available via FTP:
-
- ftp://ftp.openssl.org/source/
+For public releases, verify that the tarballs are available via FTP:
-And that they are ready for the website:
+ ls /srv/ftp/source
- ls /var/www/openssl/source
+For premium releases, verify that the tarballs are available via SFTP:
-*For OpenSSL 3.0 and on*, push your local changes to the main source repo as
-instructed by `dev/release.sh`. You may want to sanity check the pushes by
-inserting the `-n` (dry-run) option.
+ ls /srv/premium
-*For OpenSSL before 3.0*, simply push your local changes to the main source
-repo, and please do remember to push the release tags as well, which is done
-separately with the `--tags` option. You may want to sanity check the
+*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.
-## Updating the website
+*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
+may want to sanity check the pushes by inserting the `-n` (dry-run)
+option. You must specify the repository / remote and tag to be pushed:
-Push the website changes you made earlier to the OpenSSL website repo. When
-you do this, the website will get updated and a script to flush the Akamai
-CDN cache will be run. You can look at things on www-origin.openssl.org;
-the CDN-hosted www.openssl.org should only be a few minutes delayed.
+ 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
+now.
+
+When you do this for a public release, the website will get updated and a
+script to flush the Akamai CDN cache will be run.
+
+You can look at <https://automation.openssl.org/> to see the automation
+builds in action. The builder called `web` is of particular interest.
+
+You can also look at the result at <https://www-origin.openssl.org>; the
+CDN-hosted www.openssl.org should get updated withing minutes later.
# Post-publishing tasks
## Check the website
-Verify that the release notes, which are built from the CHANGES.md file
-in the release, have been updated. This is done automatically by the
-commit-hook, but if you see a problem, try the following steps on
-`dev.openssl.org`:
+*NOTE: This is **only** for public releases*
- cd /var/www/openssl
- sudo -u openssl -H make relupd
- sudo -u openssl -H ./bin/purge-one-hour
+Verify that the release notes, which are built from the CHANGES.md file
+in the release, have been updated. This is done automatically by OpenSSL
+automation; if you see a problem, check if the web build job has been
+performed yet, you may have to wait a few minutes before it kicks in.
Wait for a while for the Akamai flush to work (normally within a few minutes).
Have a look at the website and news announcement at:
Send out the announcements. Generic release announcement messages will be
created automatically by the build script and the commands you need to use
-to send them were displayed when you executed do-release.pl above.
-These are sent to openssl-users, openssl-project, and openssl-announce. They
-should be sent from the account of the person that owns the key used for signing
-the release announcement. Ensure that mutt is configured correctly - send a test
-email first if necessary.
+to send them were displayed when you executed do-release.pl above. They
+should be sent from the account of the person that owns the key used for
+signing the release announcement. Ensure that mutt is configured correctly -
+send a test email first if necessary.
If do-release.pl was used with `--move` be sure to move the announcement
-text files away from the staging directory after they have been sent. This
-is done as follows (with VERSION replaced with the version of OpenSSL to
-announce):
+text files away from the staging directory *after they have been sent*.
+This is done as follows (with VERSION replaced with the version of OpenSSL
+to announce):
- REPLYTO="openssl@openssl.org" mutt -s "OpenSSL version VERSION published" \
- openssl-project openssl-users openssl-announce \
- < /home/openssl/dist/new/openssl-VERSION.txt.asc
sudo -u openssl \
mv ~openssl/dist/new/openssl-VERSION.txt.asc ~openssl/dist/old
## Send out the Security Advisory
*The secadv file mentioned in this section is the Security Advisory
-that you copied into the web repo, up in the section
-[Update the website locally](#update-the-website-locally)*
+that you copied into the release data repo, up in the section
+[Update the release data locally](#update-the-release-data-locally)*
*This section is only applicable if this is a security release*
scp secadv_FILENAME.txt.asc dev.openssl.org:/tmp
To finish, log in on dev.openssl.org and send the signed Security
-Advisory by email as the user that signed the advisory, and then remove it:
+Advisory by email as the user that signed the advisory.
+
+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
+
+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
+
+When done, remove the email file:
+
rm /tmp/secadv_FILENAME.txt.asc
Approve the openssl-announce email. Go to
<https://mta.openssl.org/mailman/admindb/openssl-announce>
and approve the messages.
-Check the mailing list messages have arrived.
+For premium releases, approve the support-announce email as well. Go to
+<https://mta.openssl.org/mailman/admindb/support-announce> and approve the
+messages.
+
+Check that the mailing list messages have arrived.
## Unfreeze the source repository.
- ssh openssl-git@git.openssl.org unfreeze openssl
+This must be done from a checkout of the appropriate source repo:
+
+ git push --delete git@github.openssl.org:openssl/openssl.git \
+ refs/frozen/NAME
+
+or:
+
+ git push --delete git@github.openssl.org:openssl/premium.git \
+ refs/frozen/NAME
## Security fixes
projects / tools.git / blobdiff