From owner-freebsd-questions@FreeBSD.ORG Fri Feb 6 20:06:41 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CC7F106566B for ; Fri, 6 Feb 2009 20:06:41 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 967138FC16 for ; Fri, 6 Feb 2009 20:06:39 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl91-225.kln.forthnet.gr [77.49.58.225]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id n16JoaCp021313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Feb 2009 21:50:42 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n16JoaAV070504; Fri, 6 Feb 2009 21:50:36 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n16JoZw9070492; Fri, 6 Feb 2009 21:50:35 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: cpghost References: <4989B239.9090504@optiksecurite.com> <878wolpydl.fsf@kobe.laptop> <20090206165800.GB1444@phenom.cordula.ws> <871vubv66x.fsf@kobe.laptop> <20090206191157.GB2438@phenom.cordula.ws> Date: Fri, 06 Feb 2009 21:50:34 +0200 In-Reply-To: <20090206191157.GB2438@phenom.cordula.ws> (cpghost@cordula.ws's message of "Fri, 6 Feb 2009 20:11:57 +0100") Message-ID: <87myczz6np.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n16JoaCp021313 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.487, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL -0.09, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: "freebsd-questions@freebsd.org" Subject: Re: OT: SVN checkout checksumming X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 20:06:41 -0000 On Fri, 6 Feb 2009 20:11:57 +0100, cpghost wrote: >On Fri, Feb 06, 2009 at 07:14:14PM +0200, Giorgos Keramidas wrote: >>On Fri, 6 Feb 2009 17:58:00 +0100, cpghost wrote: >>>> Let's assume for a moment that you install a post-commit hook that >>>> generates a SHA-256 checksum of all the files in the latest repo >>>> revision on the svn server. >>>> >>>> For the sake of simplicity, let's assume that this file is a simple, >>>> plain text file that is named db/revs/NUMBER.sha256 where 'NUMBER' is >>>> the revision number you are check-summing. >>>> >>>> How are you going to *safely* transmit those SHA-256 checksums to the >>>> client on 'svn checkout'? >>> >>> Well, sorry to bring this back up, but again: how about signing >>> NUMBER.sha256 with a GnuPG private key belonging to the FreeBSD >>> Project? If there's a way to *safely* get the corresponding >>> public key, checking the signature of the NUMBER.sha256 files >>> would be trivial. >> >> If the signed data is not part of the actual repository, you have a >> signature for a numeric value, not a signature for the *contents* of the >> repository itself. > > Hmmm... yes, you're right. Only the digest would be signed in this > case, and that's not enough. But if the (digest, revision) pair is > signed, that would at least be useful (somewhat). > > So, let's say that NUMBER.sha256 starts with something like a comment: > > # r123456 > > > > ... > > and all this signed, would it be enough? Sorry, but no, it wouldn't be enough. There are other SCM systems where the sha256 hash is *part* of the history, like Mercurial, Git and Darcs. If you really want to be _certain_ that a particular revision is truly what it is supposed to be, using something that makes cryptographically secure hashes an integral part of the history is probably the only way to achieve that goal :/ > Even if the repository isn't signed, one can compute the digests > locally and check them with the *signed* list of digests. It may not > catch everything because of possible collisions, but wouldn't that be > already better than nothing? Yes, that might be "good enough", but it might have a slightly hard to define set of constraints. For example: * Do you publish checksums for all the files in each revision (a 'manifest' as some systems call the collection of files)? * Do you allow checksums to be recorded as a full manifest every time, or do you publish only the checksums for the files that changed since the last revision? * How do you handle separate branches? * Do svn:keywords play a role in the calculation of the checksum? If not, why? These are not as easy problems to solve as it may initially appear :(