On Fri 2019-03-15 07:49:16 -0300, David Bremner wrote:
> BTW2: In a sense everyone has other defences since the tar ball contains a
> file "version" with the version in it.

Right, if there was a standard/conventional way to indicate the package
name and version information *within* any source tarball, that would be
a great simple defense.  The closest we could come to such a convention
might actually be the name of the top-level directory within the tarball
itself: notmuch's tarball unpacks to notmuch-0.28.3/* regardless of what
the tarball's name is.  But while that practice is fairly widespread in
many other projects, i don't think it's nearly as universal a convention
as stuffing the package name and version in the tarball name
itself. (note that uscan in particular extracts the version from the
tarball name, not its contents)

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.

I suppose i could test such an attack on uscan itself, but i haven't
gotten the bandwidth to really trying it out.  If someone wants to try
it, i'd be happy to read a report!

>> David, how would you feel about generating two forms of cryptographic
>> signature per-tarball as an interim process?
>
> Yeah, that sounds fine. IIUC, the old .sha256.asc and the "new"
> .tar.gz.asc?

sure, though i'd change the .sha256.asc to be a clearsigned file instead
of the current ASCII-armored OpenPGP message that it currently is (as
Adam suggested elsewhere in this thread).  And we can ditch the .sha256
itself, which doesn't seem to be doing any useful work.

      --dkg