Re: [PATCH] build: sign tarball instead of sha256sum

Subject: Re: [PATCH] build: sign tarball instead of sha256sum

Date: Fri, 15 Mar 2019 12:48:21 -0400

To: Adam Majer, David Bremner, Carl Worth,


From: Daniel Kahn Gillmor

Hash: SHA512

On Fri 2019-03-15 15:30:56 +0100, Adam Majer wrote:
> The .spec file has (I added some comments here)
> Name:           nodejs10
> Version:        10.15.3
> Source:{version}/node-v%{version}.tar.xz
> Source1:{version}/SHASUMS256.txt
> Source2:{version}/SHASUMS256.txt.sig
> Source3:        nodejs.keyring

interesting -- i note that the thing signed here is actually a checksum
file, and not the tarball itself.  Please use this technique for notmuch
too! does this mean that you don't need the detached tarball signature?

> The .sig is verified vs. nodejs.keyring on checkin. And for build, the 
> %prep phase in start of the build has,
> # this checks the checksum
> echo "`grep node-v%{version}.tar.xz %{S:1} | head -n1 | cut -c1-64`  %{S:0}" | sha256sum -c

(i think this was line-wrapped; i unwrapped it and i hope i got the
whitespace right)

this is interesting!  I'd want to tighten up the grep a bit, and drop
the head -n1 (seems like it means "cross your fingers and hope we got
the right one", which is not great for signature verification), and it's
not clear that you need to rebuild the line itself.

If you've already verified SHASUMS256.txt.sig, Why not just:

   grep -E '^[0-9a-f]{64} [ *]node-v%{version}\.tar\.xz$' %{S:1} | sha256sum -c

(this still doesn't properly escape regex metacharacters like . in
%{version}, but it's a much tighter match than the earlier line.

> # this unpacks the tarball Source0 and changes to directory
> # node-v%{version}
> %setup -q -n node-v%{version}
> The build would break if directory is different name.

i'm assuming that this is done starting from an empty directory by
default -- otherwise it could misbehave if there was cruft leftover from
some other unpacking.

> The build would break if checksum is wrong, but that has explicit
> verification. And build would not even be attempted if *.sig wasn't
> signed by a key in the *.keyring file.

nice, this is very good.  it looks like OBS is checking:

 * cryptographic signature over the tarball name (which includes package
   and version)
 * that the tarball contains a directory named with the package and version

that's a robust check, and it looks good.

> Not only that, because the SourceX is a URL, distributions like 
> Tumbleweed that accept lots of submissions, have automated bot that will 
> download these files and compare them to what was submitted. If these 
> differ, it will reject. This actually caught NodeJS project adding ARM 
> binaries to their release after release and re-issuing the checksums. 
> Not malicious, just annoying (for me :)

It's great that you caught this!  Does tumbleweed have a "wall of shame"
for "re-released" software?  I'd love to know the history of what it has
caught.  I'm sure most are "legitimate" mistakes.  But hiding in the
noise could be some real malfeasance (which is why it'd be good to get
rid of the noise).

At this point, we're pretty far afield from notmuch -- if others are
annoyed, i'm happy to take the discussion to private mail or some other
mailing list if folks would prefer it.


notmuch mailing list