updating instructions to remind us to notify community platform owners of a freeze
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/tools/pull/190)
This splits up HOWTO-make-a-release.md into two new documents that reflect
the fact that *staging* and *publishing* a release are really two separate
things.
This also reflects that we're working towards full automation for staging
releases.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/tools/pull/145)
release-tools/release.sh and associated files should now be a good enough
replacement of release-tools/mkrelease.pl and associated files.
Therefore, HOWTO-make-a-release.md is adapted to only refer to the new
script, and release-tools/mkrelease.pl and associated files are removed.
Someone might want to ask, why shell scripts rather than perl?
The reasoning is that the OpenSSL team does most if not all its development
on Unix-like systems, and the release script is essentially a wrapper around
diverse shell commands anyway, it therefore seems sensible to use the shell
language.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/tools/pull/140)
We should send any security advisory to oss-security separately and not
cross-post it with our own lists.
We also change the text to say that security advisories should be sent to
support-announce regardless of whether a premium release has been affected.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/tools/pull/139)
We now need to upload the release files to the "Releases" section of
github - so we update the HOWTO instructions accordingly.
This also fixes a minor error that was spotted during the release.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/tools/pull/128)
Announcement emails should be sent from the email account of the owner of
the signing key, otherwise some email clients will fail to verify the key
correctly.
A longer term solution will be to have a separate release signing key.
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/tools/pull/89)
README.md in $TOOLS/release-tools/ isn't obvious to discover. It has
also aged considerably, at least in terms of OpenSSL 3.0, so needs a
serious update.
Co-authored-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/tools/pull/75)