From owner-freebsd-stable@FreeBSD.ORG Wed Oct 1 02:20:51 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A0C7AD7; Wed, 1 Oct 2014 02:20:51 +0000 (UTC) Received: from ruggedinbox.com (ruggedinbox.com [94.156.77.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA713841; Wed, 1 Oct 2014 02:20:50 +0000 (UTC) Message-ID: In-Reply-To: <20140929121648.GL75063@hub.FreeBSD.org> References: <20140928155118.GA75063@hub.FreeBSD.org> <20140929025102.GH75063@hub.FreeBSD.org> <20140929031120.GI75063@hub.FreeBSD.org> <20140929121648.GL75063@hub.FreeBSD.org> Date: Wed, 1 Oct 2014 04:18:23 +0200 Subject: svn repo verification (Re: FreeBSD 10.1-BETA3 Now Available) From: beeessdee@ruggedinbox.com To: "Glen Barber" Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 02:20:51 -0000 [Subject changed and re@ snipped, this is not 10.1-BETA3 specific.] On Mon, September 29, 2014 2:16 pm, "Glen Barber" wrote: >> > Anyway, this is not RE-related. >> >> Jah, 'RE-related' would be public verify method for whole svn repo tied >> to >> audit trail of release process. :-( >> > > I don't understand what you mean. We have a verifiable audit trail - it > is all in svn revision history. By this I mean, cryptographic hash chain and signed commits. svn revision history is audit trail, but not *verifiable* audit trail. Is there such things in svn metadata? I did not find. If yes, this should be Handbook documented (and how to use it). Important because: * Data at rest in repository, protected from intrusion or the insider attack. * Data in transit on wire not protected by svn protocol (except for persons with the ssh access) * Every person, everywhere should be able confirm downloaded commit history is exactly equals bit-for-bit what you (gjb@), Core Team, re@ have in their machines! Obscure change (example classic "if(uid==0)" to single "if(uid=0)") in critical piece even 100.000 commits old should be easy detectable by anyone. Commit bit should be attached requirement of signing of the commits. Release Engineering should positively associate each release with checksum of entire chain of commits, back to r0. Thanks!