From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Gerwitz Subject: bug#22883: Authenticating a Git checkout Date: Sun, 05 Jun 2016 22:41:02 -0400 Message-ID: <877fe3hwe9.fsf@gnu.org> References: <87io14sqoa.fsf@dustycloud.org> <87h9ep8gxk.fsf@gnu.org> <20160426001359.GA23088@jasmine> <874majg0z8.fsf@gnu.org> <87bn3iz1xc.fsf_-_@gnu.org> <87bn3hwpgo.fsf@gnu.org> <87wpm519um.fsf@gnu.org> <87h9d7e5g7.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35551) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9kVO-0006iS-SZ for bug-guix@gnu.org; Sun, 05 Jun 2016 22:43:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b9kVM-0003IB-Pz for bug-guix@gnu.org; Sun, 05 Jun 2016 22:43:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:43732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b9kVM-0003Hj-My for bug-guix@gnu.org; Sun, 05 Jun 2016 22:43:04 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87h9d7e5g7.fsf@dustycloud.org> (Christopher Allan Webber's message of "Sun, 05 Jun 2016 15:39:04 -0500") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Christopher Allan Webber Cc: 22883@debbugs.gnu.org --=-=-= Content-Type: text/plain On Sun, Jun 05, 2016 at 15:39:04 -0500, Christopher Allan Webber wrote: > One theoretical optimization: if I verify the DAG, could I store > somewhere that I've verified from commit cabba6e and upward already, so > the next time I verify it only has to verify the new commits? tbh, I haven't given this the amount of thought/research that I feel it needs. Unfortunately, you got me thinking, so here's another long message. In essence, this is equivalent to Ludo's suggestion of stopping at the last tag (if you envision, say, tagging the last processed commit) _provided that_ you also verify the commit that the tag is pointing to. My short answer is: practically speaking, it's probably fine, because you're more than likely trying to defend against an attacker that gains access to the repo, not a second-preimage attack. * * * Long answer (braindump): When I consider the potential threats, I consider that the integrity of each blob, tree, commit, etc are fairly well assured by their hashes, but depend entirely on the security of SHA-1, whose future is increasingly grim. SHA-1 does just fine for uniquely identifying objects---and if it didn't, hashes offending preimages would just be blacklisted. But it was never intended for security. The problem is pretty bad: signed commits will ensure the integrity of the commit itself (the object---as in `git cat-file -p COMMIT`); the problem is that you don't just have to find a preimage for the hashes signed in that commit: the tree hash is what really dictates the content, and that tree hash in turn identifies other trees and blobs: $ git cat-file -p 'HEAD^{tree}' ... 100644 blob 9b9481deea8cee4cc61971a752d02c04d5f0654e configure.ac 040000 tree f2b4528e1f66f3bbc4742dc4a11bd1283cd475b9 doc ... That blob contains the actual file contents. So in a large project like Guix, you have so many opportunities! You can try to find preimages for any of the trees or blobs _without having to worry about any signatures_; neither trees nor blobs are signed. With that said, if I recall correctly (and after a very brief glance at fetch-pack.c), a successful preimage attack would only affect users who haven't already fetched the legitimate object---otherwise Git wouldn't bother fetching it. I'm not sure if I find comfort in this or not: it's been used by some to dismiss the problem of collisions, but (assuming git is silent about it---and why wouldn't it be, as it wouldn't know better) that's worse, since maintainers and common contributors wouldn't notice anything wrong at all. But someone who clones fresh and compiles would be screwed. So signing commits almost certainly protects you against someone who gains access to the repository on a common origin or a maintainer/contributor's PC, provided that nobody's private key is compromised. But there doesn't seem to be any way to secure a git repository against a second-preimage attack. So given that, it doesn't really matter if you re-verify all the commits or not: an attacker doesn't need to even bother with the commit object. I guess one option is to keep a local copy of the repository, clone a fresh copy, and occasionally diff _every_ object (commit, tag, tree, blob) for differences. So if Git wants to take this issue seriously, changes have to be made. In the meantime, in addition to commit verification, you can always keep around a local copy of the repository, always clone a copy, and ensure that builds between the two are reproducible. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXVOK/AAoJEPIruBWO4w6rG6MQAJ5IEnnd/pnQNkQkolSKzFov wQHYUgmbTyqbVpfsKsH39lCgSo886W0gPcZlE+AGZWSPSS2Mrxgalca74x2vydVS xcJV+2WFq2sSY+EUfvHZh0m9Q1HMliUrWI8MN+FD4jKuBPGIvzmVFxrJZWdS8b2Z IoWpFXjqld1vMI5YxT1vX5CYpQwXNDKyc4Kpt5slOXlqKI6HPa5NDfonh+mfCuw7 DIdeS5LCLGu0tHXqDYqedroQS23UXl83lyBF9Hfu/zE/fYhdf6FQT8ijwqxK0pwg h5WNMXEzXNUIh8JLvV0FUv2eRUM5GxW2o5cr2n745z+nWZgkdn043/e4KrL+OV04 BME9g3FPRDffwPhgFD7f3N6sRIAKko/iNd38lEfIcq3OT7kSxO/NuoCOVZP/pmET nwOuvN7I5EoyaA7pu8uBL+nQpWrutpC7siLEo7erX9eyuGv36jrd1wr0pOVHr89I pWs5qSngOWopgpuhCWLgHtkDwOEB/LmTJnQ6OGVNFi4GHGo/iTdrTWOjo1x5hz2H rDeIqC9/zW9bsRxe8kxT1e9fD6QmxiSxKzh4N8hdGQ/41dYyvEfTyrNGEwETGKZ7 o6hpcPDi+1JWXMOSu0x6Pfkym39KByW/jprp0CfNTeBJj58Ub2ROUKIWgzukM5EW DMM5VaGw7J3XMSSEO5w6 =H9rN -----END PGP SIGNATURE----- --=-=-=--