Update Readme section on verifying signatures

[MylesBorins]

EDIT:

We now generate detached signatures for all release lines. There is no documentation on how to verify this. An update to the Readme would be great!

---

Original

The current process for verifying releases is outputting a warning

gpg: Signature made Thu May  5 17:56:43 2016 CDT using RSA key ID 4C206CA9
gpg: Good signature from "Evan Lucas <evanlucas@me.com>" [ultimate]
gpg:                 aka "Evan Lucas <evanlucas@keybase.io>" [ultimate]
gpg: WARNING: not a detached signature; file 'SHASUMS256.txt' was NOT verified!

A script to verify and output is included in this gist

[MylesBorins]

/cc @rvagg @nodejs/build

[jasnell]

@evanlucas

[evanlucas]

yea, I noticed this earlier. It isn't just mine though. Every release I've run against has shown the same thing (although I haven't gone back too much)

[rvagg]

OK, so here's the thing that's going on here: when you do a --verify, gpg will look at the file being verified and if there's an equivalent non-signed file then it'll assume you're working with a detached signature, which we don't do. This is happening here because you're also downloading SHASUMS256.txt and have it beside SHASUMS256.txt.asc. Try removing or renaming the former and you'll get a different result because gpg will decide it's a cleartext signed document with the sig inside the doc rather than detached from it.

But this raises an interesting point because detached signatures offer a bit more safety than we offer and maybe we should switch our signing mechanism to use them instead, or as well. The reason is that gpg will only verify the contents between -----BEGIN PGP SIGNED MESSAGE----- and -----BEGIN PGP SIGNATURE----- using the signature found within. But we are recommending a simple grep. So someone wishing to insert a bad build onto nodejs.org could just add a new line outside of the validated block with their new shasum and the filename and the file would still get verified and the invalid shasum would be grepped just fine. i.e. we don't have enough steps on our README to properly handle this case so it's actually not all that secure.

Detached signatures give you a signature for an entire file in a separate file. If we shipped a SHASUMS256.txt.sig as a detached signature then you'd download that as well as SHASUMS256.txt and gpg --verify would check the sig against the original and verify the whole thing. Then our instructions on the README about using grep against SHASUMS256.txt would be perfectly acceptable.

@nodejs/crypto @jbergstroem can you --verify my logic above ^?

[bnoordhuis]

@rvagg Yes, that's right. I assume the .asc is created with gpg --clearsign --sign <file>? Changing that to gpg -b <file> would produce a detached signature.

[jasnell]

Yep, spot on explanation. I definitely think moving to the detached signature would be the best choice here.

[MylesBorins]

thanks for digging in. +1 on detached signature as well

[mhdawson]

+1 for detached signatures.

[evanlucas]

Works for me

[Fishrock123]

Detached seems better to me, will doing this impact anyone?

[jasnell]

Not likely. The verification step is essentially the same.

[MylesBorins]

What needs to be done to move to detached signatures?