From owner-freebsd-questions@FreeBSD.ORG Sat Nov 17 20:42:14 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7EAD5A4; Sat, 17 Nov 2012 20:42:14 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm2.ukr.net (fsm2.ukr.net [195.214.192.121]) by mx1.freebsd.org (Postfix) with ESMTP id 64F188FC14; Sat, 17 Nov 2012 20:42:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=KkVc4Kfh0xFnqQkT+o5OWwY4+X3OcSmK7ZyH2sXT6s0=; b=Ye1wH+yTCZdZfb3s8jgwrkOGF/I+hXNiD2eA1IiusepDJ9zqGUKVnR5njMVhKSggARZ8mLbUrnc03mIPVeJW5JmJ46NxCYgzGfem1a/XGLoS4mQNHM8SO7G+Igzsir2C9A8SE+iZnhJ+mwuMFmaOxB7QlO/ss4/fCEPsJl4CSzI=; Received: from [178.137.138.140] (helo=nonamehost) by fsm2.ukr.net with esmtpsa ID 1TZojz-000FQR-Sl ; Sat, 17 Nov 2012 22:11:48 +0200 Date: Sat, 17 Nov 2012 22:11:43 +0200 From: Ivan Klymenko To: grarpamp Subject: Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident] Message-ID: <20121117221143.41c29ba2@nonamehost> In-Reply-To: References: X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWpqak/Pz/i4uIfHx8GBwZwcHAQEBA6o92AAAACHElEQVQ4jWWUTY7bMAyF6QzUPSEoa8PFHEBgqwuM4bVVg7MvZOj+R+ijpMTpjIwgkT7z75EKrdfattpXERG6zqvUOtAr2LCRYfEKcB4l/Q+2cc6XjQH7hv+2YZYreIk5nevZEPvuzUzptizHLzgDMnC5Wpbl7ewJlOEqlQF+DlCjgVLki0WV6FMDMsBxjlJiQulIznwZ+DxHiQyDyIg0wN3Oo6o6ZQ5s5AIfar+W2Wlmz+kCcb8tg6j3voMEwNrBQk69dDBDqw/urpqJH+m+Q6u/4QnoAeYpnUXC/s1iup9rhCd6xMgAqdDyAyFegbKkVAHeLCcOulPLawaoUIDos4M88iLNrVkU7uu5ccTDO6naJzWLum51C6Yb7y4HKKbdArLWir0PBiS8glJRBZHeyHl7J9lENpAC6qT9NlNG4u5hsVYDyJP6mlJJtY3oVju4WSUzHal1sDU17NASoBWSk40J2eBLBJhYrVmzC5gVALGpNIAiQgN6eGstOp9Oa6zFbbLTISYi28BGZDRUJKWeroECkCEkzXjUtbmmaKMfAx2RfbT69/cO+tgHcmx6AfyZOmj3NDIah0F0GB66d4CrdIoplNFFGHSpSheRxbo0W4S8azNItEoMWbw3uXAeJgCrmX5joz7CGXqSg6PcryEhnFr/C1C2ntPxBOYbdwY+8dO3+wZJyFlbMX9s8zNnvp/tLwAv03NB4j3HVpn8Awwm+GrlP6MVAAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-hubs@freebsd.org, freebsd-questions@freebsd.org, freebsd-security@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 20:42:15 -0000 =D0=92 Sat, 17 Nov 2012 15:00:06 -0500 grarpamp =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > http://www.freebsd.org/news/2012-compromise.html > http://it.slashdot.org/story/12/11/17/143219/freebsd-project-discloses-se= curity-breach-via-stolen-ssh-key >=20 > This is not about this incident, but about why major opensource > projects need to be using a repository that has traceable, verifiable, > built-in cryptographic authentication. >=20 > Any of hundreds of committer and admin accounts could be compromised > with the attacker silently editing the repo. The same applies to > any of those accounts going rogue. Backtrack diffing from a breach > to 'see what changed' is not the ideal option. You really need to > be using a strong repo so that any attack on it is null from the > start. Another problem is bit rot wherever it may occur... disk, > hardware, the wire, EMP and other systems. >=20 > As it is now, we have no way to verify that what we get on pressed > CD's, ISO's, FTP sites, torrents, etc is strongly linked back to > the original repo. Signing over a hash of the ISO is *not* the same > as including the strong repo hash (commit) that was used to build > the release and then signing over that and the ISO. We can't know > that our local repository updates match the master. ports.tar.gz > has no authentication either. Nor does anything in the entire project > that originates from the current SVN/CVS repo... webpages, docs, > tools, source tarballs, etc. The FTP packages aren't signed, and > there are weak MD5's used in various parts of the install/package > tools, mirrors, etc. We can't trade hashes amongst people. It's all > just a bunch of random bits that someone may or may not have signed > over. And even if signed they still wouldn't be strongly linked > back to the master repo. Having such a disconnect at the root of > everything you do is simply not good practice these days. >=20 > And these days, Git is what people and projects are moving to, and > its rate of adoption and prevalence have essentially won out over > all the rest in the new 'revision control 2.0 world'. And knowing > Git is now more or less essential if you want to participate in a > wide variety of community development, ref: github, etc. >=20 > The FreeBSD project needs to be providing both itself, and its users > and benefactors with verifiable assurance that its repository, and > any copies and derived products, are authentic and intact. >=20 > Don't argue against such a repository feature, or the cost to move, > or bury your head in the sand by saying it could never happen to us... >=20 > Take this as a real opportunity to lead amongst the major opensource > projects like Linux, and among the BSD's (like DragonFly has), and > move to Git. >=20 > Once the root is fixed, you can push out secure distribution and > update models from there. It all starts at the root and can't be > done without it. >=20 > https://www.kernel.org/pub/software/scm/git/docs/git-fsck.html > Verifies the connectivity and validity of the objects in the database >=20 > http://git-scm.com/about/info-assurance > The data model that Git uses ensures the cryptographic integrity > of every bit of your project. Every file and commit is checksummed > and retrieved by its checksum when checked back out. It's impossible > to get anything out of Git other than the exact bits you put in. > It is also impossible to change any file, date, commit message, > or any other data in a Git repository without changing the IDs of > everything after it. This means that if you have a commit ID, you > can be assured not only that your project is exactly the same as > when it was committed, but that nothing in its history was changed. >=20 > https://en.wikipedia.org/wiki/Git_(software) > The Git history is stored in such a way that the id of a particular > revision (a "commit" in Git terms) depends upon the complete > development history leading up to that commit. Once it is published, > it is not possible to change the old versions without it being > noticed. The structure is similar to a hash tree, but with additional > data at the nodes as well as the leaves. >=20 > Some references... > http://git-scm.com/ > https://github.com/ > http://gitweb.dragonflybsd.org/dragonfly.git > https://git.kernel.org/?p=3Dlinux/kernel/git/stable/linux-stable.git LOL And how will this help Linux? http://lwn.net/Articles/457142/