Node: Update Readme section on verifying signatures
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 <[email protected]>" [ultimate]
gpg: aka "Evan Lucas <[email protected]>" [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
All 26 comments
/cc @rvagg @nodejs/build
MylesBorins
on 18 May 2016
@evanlucas
jasnell
on 18 May 2016
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)
evanlucas
on 18 May 2016
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 ^?
rvagg
on 18 May 2016
@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.
bnoordhuis
on 18 May 2016
Yep, spot on explanation. I definitely think moving to the detached signature would be the best choice here.
jasnell
on 18 May 2016
thanks for digging in. +1 on detached signature as well
MylesBorins
on 18 May 2016
+1 for detached signatures.
mhdawson
on 19 May 2016
Works for me
evanlucas
on 19 May 2016
Detached seems better to me, will doing this impact anyone?
Fishrock123
on 19 May 2016
Not likely. The verification step is essentially the same.
jasnell
on 19 May 2016
What needs to be done to move to detached signatures?
MylesBorins
on 7 Jun 2016
@TheAlphaNerd https://github.com/nodejs/node/issues/6821#issuecomment-220086958, basically.
bnoordhuis
on 7 Jun 2016
I'd like to handle this one pls
rvagg
on 8 Jun 2016
@rvagg any movement on this?
MylesBorins
on 22 Jul 2016
rvagg
on 13 Oct 2016
Will leave this issue open as a reminder to update the README with instructions on using the new sigs. They are live for all releases now, e.g. https://nodejs.org/download/release/v7.0.0/
rvagg
on 3 Nov 2016
@rvagg Would it be possible to backport this to the current LTS branch?
lots0logs
on 11 Mar 2017
Ping @nodejs/lts
jasnell
on 11 Mar 2017
@lots0logs the fix landed in v4.6.2 and v6.9.1
MylesBorins
on 11 Mar 2017
I've changed the title of this issue to make it a good first contribution. We need to update the Readme with instructions on how to verify releases.
MylesBorins
on 26 Apr 2017
Would be happy to work on this if no one else has already done so!
neeharv
on 26 Apr 2017
Hi @MylesBorins , @neeharv ,
Even I would like to contribute in any way possible and wanted to work on this.
So please share & let me know, how can I help. Thank you!
Cheers!
bthemukul
on 27 Apr 2017
@MylesBorins Should this be closed? The readme contains instructions about verifying via SHASUMS256.txt.asc
maclover7
on 23 Aug 2017
This is still an active TODO. We need to switch to recommending use of SHASUM256.txt and SHASUM256.txt.sig rather than the .asc files for reasons I stated above when making the case for detached signatures. Since we've been doing detached signatures for many months now it's time to update the README with the safer recommendation.
rvagg
on 23 Aug 2017
It might be worth mentioning that one shouldn't rely on the exit code of gpg --verify, as it exits with 0, i.e. success, even if the key has been revoked or expired, as long as the signature was made with that key. So if someone steals nodejs's release key, makes a malicious release with it and nodejs people revoke it, gpg --verify would still return 0 even with gpg knowing that the key is revoked.
nurupo
on 27 May 2019
Related issues
filipesilvaa
路
3Comments
willnwhite
路
3Comments
srl295
路
3Comments
sandeepks1
路
3Comments
jmichae3
路
3Comments
Most helpful comment
OK, so here's the thing that's going on here: when you do a
--verify,gpgwill 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 downloadingSHASUMS256.txtand have it besideSHASUMS256.txt.asc. Try removing or renaming the former and you'll get a different result becausegpgwill 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
gpgwill only verify the contents between-----BEGIN PGP SIGNED MESSAGE-----and-----BEGIN PGP SIGNATURE-----using the signature found within. But we are recommending a simplegrep. 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.sigas a detached signature then you'd download that as well asSHASUMS256.txtandgpg --verifywould check the sig against the original and verify the whole thing. Then our instructions on the README about usinggrepagainstSHASUMS256.txtwould be perfectly acceptable.@nodejs/crypto @jbergstroem can you
--verifymy logic above ^?