On 3/15/19 2:47 PM, Daniel Kahn Gillmor wrote:
> Do you know of any code that actually makes use of that defense?  That
> is, any code that says "fetch version X of package foo and its
> cryptographic signatures; verify the signature over the tarball, and
> also verify that it unpacks to a directory named foo-X/ before returning
> success" ?  That would be great if it's out there and i'm unaware of it.

We do. For example, nodejs10,

   https://build.opensuse.org/package/show/devel:languages:nodejs/nodejs10

The .spec file has (I added some comments here)

Name:           nodejs10
Version:        10.15.3
Source:         https://nodejs.org/dist/v%{version}/node-v%{version}.tar.xz
Source1:        https://nodejs.org/dist/v%{version}/SHASUMS256.txt
Source2:        https://nodejs.org/dist/v%{version}/SHASUMS256.txt.sig
Source3:        nodejs.keyring

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

# 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. 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.

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 :)

- Adam
_______________________________________________
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch