From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: David Bremner <david@tethera.net>, Adam Majer <amajer@suse.de>,
Carl Worth <cworth@cworth.org>,
notmuch@notmuchmail.org
Subject: Re: [PATCH] build: sign tarball instead of sha256sum
Date: Fri, 15 Mar 2019 09:47:28 -0400 [thread overview]
Message-ID: <87o96cw8pb.fsf@fifthhorseman.net> (raw)
In-Reply-To: <87ftrobefn.fsf@tethera.net>
[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2019-03-15 13:49 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-06 10:48 Release signatures Adam Majer
2019-02-10 13:51 ` David Bremner
2019-02-11 23:37 ` Carl Worth
2019-02-13 2:17 ` [PATCH] build: sign tarball instead of sha256sum David Bremner
2019-03-12 10:55 ` David Bremner
2019-03-14 22:51 ` Daniel Kahn Gillmor
2019-03-15 1:49 ` David Bremner
2019-03-15 8:48 ` Daniel Kahn Gillmor
2019-03-15 1:53 ` Adam Majer
2019-03-15 8:58 ` Daniel Kahn Gillmor
2019-03-15 10:49 ` David Bremner
2019-03-15 13:47 ` Daniel Kahn Gillmor [this message]
2019-03-15 13:56 ` David Bremner
2019-03-15 14:50 ` Daniel Kahn Gillmor
2019-03-15 14:30 ` Adam Majer
2019-03-15 16:48 ` Daniel Kahn Gillmor
2019-03-23 11:21 ` [PATCH] build: distribute signed sha256sums Daniel Kahn Gillmor
2019-03-23 12:35 ` [PATCH v2 1/3] build: ensure that SHA256_FILE is built Daniel Kahn Gillmor
2019-03-23 12:35 ` [PATCH v2 2/3] build: distribute signed sha256sums Daniel Kahn Gillmor
2019-03-23 12:35 ` [PATCH v2 3/3] build: Rename GPG_FILE to DETACHED_SIG_FILE Daniel Kahn Gillmor
2019-03-27 21:02 ` [PATCH v2 1/3] build: ensure that SHA256_FILE is built David Bremner
2019-03-15 11:35 ` [PATCH] build: sign tarball instead of sha256sum Adam Majer
2019-03-15 13:37 ` Daniel Kahn Gillmor
2019-03-15 14:18 ` Adam Majer
2019-03-15 13:50 ` David Bremner
2019-03-15 15:35 ` Daniel Kahn Gillmor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o96cw8pb.fsf@fifthhorseman.net \
--to=dkg@fifthhorseman.net \
--cc=amajer@suse.de \
--cc=cworth@cworth.org \
--cc=david@tethera.net \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).