mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-09 17:38:00 +00:00
5cac6013b7
In recent releases we've taken to making the actual release build (or rather, candidates for it) ahead of time so that we can do some slightly more thorough last-minute testing of the exact binaries that we're going to release to everyone. It's time I actually wrote that procedure down in the checklist, so that I remember what it is. In particular, we had the idea that we should not properly GPG-sign the release until the last moment, and use the presence of a set of full GPG signatures as a means of distinguishing the real release build from an RC that accidentally got out into the wild somehow. This checklist update formalises that too, and documents the method I used of ensuring the binaries weren't tampered with between RC building and release signing (by making a signature on just the sha512sums). I also include in this commit an extra command-line option to sign.sh to make that preliminary signature step more convenient.
213 lines
8.8 KiB
Plaintext
213 lines
8.8 KiB
Plaintext
Checklists for PuTTY administrative procedures
|
|
==============================================
|
|
|
|
Going into pre-release stabilisation
|
|
------------------------------------
|
|
|
|
When we begin to work towards a release and want to enabling
|
|
pre-releases on the website:
|
|
|
|
- Make a branch whose tip will be the current state of the
|
|
pre-release. Regardless of whether the branch is from master or
|
|
from a prior release branch, the name of the branch must now be in
|
|
the form 'pre-X.YZ', or else the website will fail to link to it
|
|
properly in gitweb and the build script will check out the wrong
|
|
thing.
|
|
|
|
- Edit ~/adm/puttysnap.sh on my build machine to set $prerelver correctly.
|
|
|
|
- Edit ~/adm/puttysnap.sh on the master machine to enable pre-release
|
|
builds, by changing the 'if false' to 'if true'.
|
|
|
|
- Put the website into pre-release mode, by defining prerel_version()
|
|
in components/Base.mc to return the upcoming version number. Also
|
|
add a news announcement in components/news. (Previous naming
|
|
convention has been to name it in the form 'X.YZ-pre.mi'.)
|
|
|
|
Things to do during the branch-stabilisation period:
|
|
|
|
- Go through the source (including the documentation), and the
|
|
website, and review anything tagged with a comment containing the
|
|
word XXX-REVIEW-BEFORE-RELEASE. (Any such comments should state
|
|
clearly what needs to be done.)
|
|
|
|
- Do some testing of the Windows version with Minefield (you can
|
|
build a Minefield version using 'bob . XFLAGS=-DMINEFIELD'), and of
|
|
the Unix version with valgrind. In particular, any headline
|
|
features for the release should get a workout with memory checking
|
|
enabled!
|
|
|
|
Making a release candidate build
|
|
--------------------------------
|
|
|
|
- Make a directory to hold all the release paraphernalia. I usually
|
|
call it ~/src/putty/X.YZ (where X.YZ will stand throughout for the
|
|
version number). In that directory, make a git clone of the PuTTY
|
|
repository, where you can make release-related commits and tags
|
|
tentatively, and keep them out of the way of any 'git push' you
|
|
might still be doing in other checkouts.
|
|
|
|
- Double-check that we have removed anything tagged with a comment
|
|
containing the words XXX-REMOVE-BEFORE-RELEASE or
|
|
XXX-REVIEW-BEFORE-RELEASE. ('git grep XXX-RE' should only show up
|
|
hits in this file itself.)
|
|
|
|
- Now update the version numbers and the transcripts in the docs, by
|
|
checking out the release branch in the release-specific checkout
|
|
and running
|
|
|
|
./release.pl --version=X.YZ --setver
|
|
|
|
Then check that the resulting automated git commit has updated the
|
|
version number in the following places:
|
|
|
|
* putty/LATEST.VER
|
|
* putty/doc/plink.but
|
|
* putty/doc/pscp.but
|
|
* putty/windows/putty.iss (four times, on consecutive lines)
|
|
|
|
and also check that it has reset the definition of 'Epoch' in
|
|
Buildscr.
|
|
|
|
- Make the release tag, pointing at the version-update commit we just
|
|
generated.
|
|
|
|
- If the release is on a branch (which I expect it generally will
|
|
be), merge that branch to master.
|
|
|
|
- Make a release-candidate build from the release tag, and put the
|
|
build.out and build.log dfiles somewhere safe. Normally I store
|
|
these in an adjacent directory, so I'll run a command like
|
|
bob -o ../X.YZ/build-X.YZ-rcN.out -l ../X.YZ/build-X.YZ-rcN.log -c X.YZ . RELEASE=X.YZ
|
|
This should generate a basically valid release directory as
|
|
`build-X.YZ-rcN.out/putty', and provide link maps and sign.sh
|
|
alongside that.
|
|
|
|
- Double-check in build-X.YZ-rcN.log that the release was built from
|
|
the right git commit.
|
|
|
|
- Make a preliminary gpg signature, but don't run the full release-
|
|
signing procedure. (We use the presence of a full set of GPG
|
|
signatures to distinguish _abandoned_ release candidates from the
|
|
one that ended up being the release.) In the 'build.X.YZ-rcN.out'
|
|
directory, run
|
|
sh sign.sh -r -p putty
|
|
and you should only have to enter the release key passphrase once,
|
|
which will generate a clearsigned file called
|
|
sha512sums-preliminary.gpg _outside_ the 'putty' subdirectory.
|
|
|
|
- For my own safety, make the release candidate build read-only.
|
|
chmod -R a-w build-X.YZ-rcN.out build-X.YZ-rcN.log
|
|
|
|
- Now do some checking of the release binaries, and pass them to the
|
|
rest of the team to do some as well. Do at least these things:
|
|
* make sure they basically work
|
|
* check they report the right version number
|
|
* if there's any easily observable behaviour difference between
|
|
the release branch and master, arrange to observe it
|
|
* test the Windows installer
|
|
* test the Unix source tarball.
|
|
|
|
Preparing to make the release
|
|
-----------------------------
|
|
|
|
- Write a release announcement (basically a summary of the changes
|
|
since the last release). Squirrel it away in
|
|
thyestes:src/putty-local/announce-<ver> in case it's needed again
|
|
within days of the release going out.
|
|
|
|
- Update the website, in a local checkout:
|
|
* Write a release file in components/releases which identifies the
|
|
new version, a section for the Changes page, and a news
|
|
announcement for the front page.
|
|
+ The one thing this can't yet contain is the release date;
|
|
that has to be put in at the last minute, when the release
|
|
goes live. Fill in 'FIXME', for the moment.
|
|
* Disable the pre-release sections of the website (if previously
|
|
enabled), by editing prerel_version() in components/Base.mc to
|
|
return undef.
|
|
|
|
- Update the wishlist, in a local checkout:
|
|
* If there are any last-minute wishlist entries (e.g. security
|
|
vulnerabilities fixed in the new release), write entries for
|
|
them.
|
|
* If any other bug fixes have been cherry-picked to the release
|
|
branch (so that the wishlist mechanism can't automatically mark
|
|
them as fixed in the new release), add appropriate Fixed-in
|
|
headers for those.
|
|
|
|
- Sign the release in full. In the `build-X.YZ-rcN.out' directory,
|
|
re-verify that the preliminary signed checksums file has a correct
|
|
signature on it and also matches the files you're about to sign for real:
|
|
gpg -d sha512sums-preliminary.gpg | (cd putty; sha512sum -c)
|
|
If the combined output of that pipeline reports both a good
|
|
signature (from the release key) and a successful verification of
|
|
all the sha512sums, then all is well, so now run
|
|
sh sign.sh -r putty
|
|
and enter the release key passphrase a lot of times.
|
|
|
|
The actual release procedure
|
|
----------------------------
|
|
|
|
Once all the above preparation is done and the release has been built
|
|
locally, this is the procedure for putting it up on the web.
|
|
|
|
- Make a final adjustment to your local website changes, filling in
|
|
the release date in components/releases/X.YZ.mi.
|
|
|
|
- Upload the release itself and its link maps to everywhere it needs
|
|
to be, by running this in the build.out directory:
|
|
../release.pl --version=X.YZ --upload
|
|
|
|
- Check that downloads via version-numbered URLs all work:
|
|
../release.pl --version=X.YZ --precheck
|
|
|
|
- Switch the 'latest' links over to the new release:
|
|
* Update the HTTP redirect at the:www/putty/htaccess .
|
|
* Update the FTP symlink at chiark:ftp/putty-latest .
|
|
|
|
- Now verify that downloads via the 'latest' URLs are all redirected
|
|
correctly and work:
|
|
../release.pl --version=X.YZ --postcheck
|
|
|
|
- Push all the git repositories:
|
|
* run 'git push' in the website checkout
|
|
* run 'git push' in the wishlist checkout
|
|
* push from the main PuTTY checkout. Typically this one will be
|
|
pushing both the release tag and an update to the master branch,
|
|
plus removing the pre-release branch, so you'll want some
|
|
commands along these lines:
|
|
git push origin master # update the master branch
|
|
git push origin --tags # should push the new release tag
|
|
git push origin :pre-X.YZ # delete the pre-release branch
|
|
|
|
- Run ~/adm/puttyweb.sh on thyestes to update the website after all
|
|
those git pushes.
|
|
|
|
- Check that the unpublished website on thyestes looks sensible.
|
|
|
|
- Run webupdate, so that all the changes on thyestes propagate to
|
|
chiark. Important to do this _before_ announcing that the release
|
|
is available.
|
|
|
|
- After running webupdate, run update-rsync on chiark and verify that
|
|
the rsync mirror package (~/ftp/putty-website-mirror) contains a
|
|
subdirectory for the new version and that the links from its
|
|
latest.html point into that subdirectory.
|
|
|
|
- Announce the release!
|
|
+ Construct a release announcement email whose message body is the
|
|
announcement written above, and which includes the following
|
|
headers:
|
|
* Reply-To: <putty@projects.tartarus.org>
|
|
* Subject: PuTTY X.YZ is released
|
|
+ Mail that release announcement to
|
|
<putty-announce@lists.tartarus.org>.
|
|
+ Post it to comp.security.ssh.
|
|
+ Mention it in <TDHTT> on mono.
|
|
|
|
- Edit the master ~/adm/puttysnap.sh to disable pre-release builds,
|
|
if they were previously enabled.
|
|
|
|
- Relax (slightly).
|