tools: add release tool, remove old tools (WIP) #681

rvagg · 2015-01-31T12:18:51Z

Not finished, pushing now in case people want to give feedback.

This is a release tool to be used by those authorized by the TC to create and promote releases. The person doing the releases will need to:

Have a commit-bit to be able to commit in src/node_version.h, update the changelog and tag a release
Have access to Jenkins to run the iojs+release job
Be able to access the [email protected] account by having their SSH key on the server (the dist user controls the /releases/ directory, the staging user is used by the release build servers to upload their binaries prior to them being promoted by the dist account).
Have their GPG key fingerprint listed on the README so the SHASUMS file for their release(s) can be verified

This is nearly ready, I just have some minor items to sort out but we'll get this in to use for the 1.1.0 in #674 where @chrisdickinson will be my guinea-pig! There should also be a document in doc/ to go along with this to explain the process and how to cut a release.

I also need to update the server-side scripts that pair with this in the https://github.com/iojs/build repo, some of it is already there but I need to be able to publicly show the whole lot of this process.

rvagg · 2015-02-01T12:35:36Z

Should be ready to merge now I think. Please review @chrisdickinson (and anyone else that wants to).

I've added a verbose releases.md document that describes the release process for anyone authorized to make a release. I don't see this as a final state but simply documenting how it works now; I imagine we'll be iterating on this over time and we'll need to keep this updated.

Also, @chrisdickinson, can you give me your SSH pubkey, you have 3 listed here.

I just need to get Chris' key onto the web server and this is ready to roll I think. I also need to get more stuff into the build repo so I can show what's actually running on the server to make this work, that's not blocking a release but I'll get to it ASAP.

rvagg · 2015-02-01T12:36:22Z

Oh, I changed the README to include a section on downloading binaries and some stuff about how to verify checksums and verify checksum files using GPG.

jbergstroem · 2015-02-01T12:53:26Z

tools/release.sh

@@ -0,0 +1,121 @@
+#!/bin/bash


how about env bash instead? bash lives elsewhere on FreeBSD and some other systems.

rvagg · 2015-02-01T23:43:34Z

changed to #!/usr/bin/env bash as per @jbergstroem's suggestion
introduced a cat and prompt once SHASUMS256.txt has been signed to allow the user to see what they are uploading, as per @jbergstroem's suggestion
introduced a check that the git tag for vx.y.z is signed with the same key you're using to sign a release
introduced a separate release.sh -s version mode where you can do only the checksum & sign step for a version that's already been prompted--in case something goes wrong with the original signing (like you get your GPG password wrong 3 times and it bails)

Fishrock123 · 2015-02-02T00:43:36Z

tools/build-changelog.sh

-  | sed -E 's|__VERSION__|v'$(python tools/getnodeversion.py)'|g' \
-  > out/doc/changelog.html
-
-rm out/doc/changelog-body.html


What do we use for the changelog now?

nada, that stuff was for changelog.html, which we don't publish (yet); we just point people to CHANGELOG.md currently.

When we come up with a better strategy we can fix this, however I think this might be something that the @iojs/website team takes responsibility for building something for coming up wtih something much prettier for.

For details on how to build the CHANGELOG.md entry itself, see doc/releases.md above.

rvagg · 2015-02-02T00:51:20Z

Removed the stale changelog & email targets from the Makefile, we don't use them and if we do I'm sure the website team can come up with something better

bnoordhuis · 2015-02-02T15:44:24Z

README.md

@@ -209,6 +265,7 @@ information about the governance of the io.js project, see
 * **Colin Ihrig** ([@cjihrig](https://github.com/cjihrig)) &lt;[email protected]&gt; (Technical Committee)
 * **Mikeal Rogers** ([@mikeal](https://github.com/mikeal)) &lt;[email protected]&gt;
 * **Rod Vagg** ([@rvagg](https://github.com/rvagg)) &lt;[email protected]&gt;
+<br>Release GPG key: DD8F2338BAE7501E3DD5AC78C273792F7D83545D


Maybe a naive question but can't we use a single master key with as many sub-keys as there are release managers? It would make all releases be signed by "io.js Release Engineering <[email protected]>" (or whatever we decide to call ourselves) and it makes revocation a little easier. Master key management is an open issue, though; who gets to own it?

Good question, to which I don't have a simple answer unfortunately.

My personal bias is towards decentralising this and making individuals responsible for signing their releases with their own keys, simply because I think decentralisation in most aspects of the project are more healthy for the community focus and ethos that we're trying to foster. It also makes that individual properly responsible for that release rather than it just being a mechanical task.

However, I don't have any strong technical objections to a more rigid signing mechanism if others prefer that. Perhaps a question for @iojs/tc.

@rvagg

Also added binary download documentation to the README.md and GPG release key fingerprint for @rvagg.

chrisdickinson · 2015-02-03T21:23:18Z

doc/releases.md

+
+A SHASUMS256.txt file is produced for every promoted build, nightly and releases. Additionally for releases, this file is signed by the individual responsible for that release. In order to be able to verify downloaded binaries, the public should be able to check that the SHASUMS256.txt file has been signed by someone who has been authorized to create a release.
+
+The GPG keys should be fetchable from a known third-party keyserver, currently the SKS Keyservers at <https://sks-keyservers.net> are recommended. Use the [submission](https://sks-keyservers.net/i/#submit) form to submit a new GPG key. Keys should be fetchable via:


I'm getting an insecure connection warning when I try to submit my pubkey to this server. Is this something I should be worried about?

Btw, is there any reason to not use https://pgp.mit.edu/ ?

Eventually went ahead with sending my pubkey despite the insecure connection. Was rewarded with a 500 Internal Server Error. ):

The only reason I chose sks-keyservers.net was because the only precedent I'm aware of for checking signed shasums is in the Docker images for both Node (official Docker ones) and io.js and that's what they've chosen to use. I don't know the reasoning behind this but I went with that as an established convention.

I'm happy to change based on recommendation, @bnoordhuis also had some thoughts about PGP keys so we should chat about this tomorrow at TC.

Ok, sounds like a good topic for @iojs/tc agenda. @rvagg let's land it the way it is for now, we will fix it later.

bnoordhuis · 2015-02-03T21:40:05Z

LGTM FWIW

@rvagg

Also added binary download documentation to the README.md and GPG release key fingerprint for @rvagg. PR-URL: #681 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Fedor Indutny <[email protected]>

rvagg · 2015-02-03T22:03:22Z

landed @ df48faf, thanks

chrisdickinson · 2015-02-03T22:20:08Z

doc/releases.md

+
+```
+git push origin branch vx.y.z
+# where "branch" is the working branch and "vx.y.z" the the release version


(we may later add e.g., v1.x here)

Fishrock123 added this to the v1.1.0 milestone Jan 31, 2015

rvagg force-pushed the release-tooling branch from 4bd3fc2 to 5af3cd0 Compare February 1, 2015 12:31

rvagg force-pushed the release-tooling branch from 5af3cd0 to 593de01 Compare February 1, 2015 12:39

jbergstroem reviewed Feb 1, 2015
View reviewed changes

tools/release.sh

@@ -0,0 +1,121 @@

#!/bin/bash

Copy link

Member

jbergstroem Feb 1, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about env bash instead? bash lives elsewhere on FreeBSD and some other systems.

rvagg force-pushed the release-tooling branch from 593de01 to 77ccc36 Compare February 1, 2015 23:40

Fishrock123 reviewed Feb 2, 2015
View reviewed changes

rvagg force-pushed the release-tooling branch from 77ccc36 to 8bb60f0 Compare February 2, 2015 00:50

bnoordhuis reviewed Feb 2, 2015
View reviewed changes

rvagg force-pushed the release-tooling branch from 8bb60f0 to 8bfb7c4 Compare February 3, 2015 01:42

tools: add release tool and docs, remove old tools

034d4be

Also added binary download documentation to the README.md and GPG release key fingerprint for @rvagg.

rvagg force-pushed the release-tooling branch from 8bfb7c4 to 034d4be Compare February 3, 2015 02:16

Fishrock123 mentioned this pull request Feb 3, 2015

Release Proposal: v1.1.0 #674

Closed

chrisdickinson reviewed Feb 3, 2015
View reviewed changes

rvagg closed this Feb 3, 2015

rvagg mentioned this pull request Feb 3, 2015

Release PGP key strategy and policy #709

Closed

chrisdickinson reviewed Feb 3, 2015
View reviewed changes

jefeaguila mentioned this pull request Feb 11, 2024

[Snyk] Fix for 1 vulnerabilities jefeaguila/node#37

Open

buzzlightyear726 mentioned this pull request Feb 11, 2024

[Snyk] Fix for 1 vulnerabilities buzzlightyear726/node#39

Open

jefeaguila mentioned this pull request Feb 11, 2024

[Snyk] Fix for 1 vulnerabilities jefeaguila/node#41

Open

buzzlightyear726 mentioned this pull request Feb 11, 2024

[Snyk] Fix for 1 vulnerabilities buzzlightyear726/node#44

Open

Renukaloch mentioned this pull request Feb 11, 2024

[Snyk] Fix for 1 vulnerabilities Renukaloch/node#26

Open

buzzlightyear726 mentioned this pull request Feb 12, 2024

[Snyk] Fix for 1 vulnerabilities buzzlightyear726/node#51

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

tools: add release tool, remove old tools (WIP) #681

tools: add release tool, remove old tools (WIP) #681

rvagg commented Jan 31, 2015

rvagg commented Feb 1, 2015

rvagg commented Feb 1, 2015

jbergstroem Feb 1, 2015

rvagg commented Feb 1, 2015

Fishrock123 Feb 2, 2015

rvagg Feb 2, 2015

rvagg commented Feb 2, 2015

bnoordhuis Feb 2, 2015

rvagg Feb 3, 2015

chrisdickinson Feb 3, 2015

indutny Feb 3, 2015

chrisdickinson Feb 3, 2015

rvagg Feb 3, 2015

indutny Feb 3, 2015

bnoordhuis commented Feb 3, 2015

rvagg commented Feb 3, 2015

chrisdickinson Feb 3, 2015


		A SHASUMS256.txt file is produced for every promoted build, nightly and releases. Additionally for releases, this file is signed by the individual responsible for that release. In order to be able to verify downloaded binaries, the public should be able to check that the SHASUMS256.txt file has been signed by someone who has been authorized to create a release.

		The GPG keys should be fetchable from a known third-party keyserver, currently the SKS Keyservers at <https://sks-keyservers.net> are recommended. Use the [submission](https://sks-keyservers.net/i/#submit) form to submit a new GPG key. Keys should be fetchable via:

tools: add release tool, remove old tools (WIP) #681

tools: add release tool, remove old tools (WIP) #681

Conversation

rvagg commented Jan 31, 2015

rvagg commented Feb 1, 2015

rvagg commented Feb 1, 2015

Choose a reason for hiding this comment

rvagg commented Feb 1, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rvagg commented Feb 2, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bnoordhuis commented Feb 3, 2015

rvagg commented Feb 3, 2015

Choose a reason for hiding this comment