Date: Sat, 17 Nov 2012 22:11:43 +0200 From: Ivan Klymenko <fidaj@ukr.net> To: grarpamp <grarpamp@gmail.com> Cc: freebsd-hackers@freebsd.org, freebsd-hubs@freebsd.org, freebsd-questions@freebsd.org, freebsd-security@freebsd.org Subject: Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident] Message-ID: <20121117221143.41c29ba2@nonamehost> In-Reply-To: <CAD2Ti29UoFcHendR8CcdQ4FPNW1HH0O47B1i3JW00Lke2m2POg@mail.gmail.com> References: <CAD2Ti29UoFcHendR8CcdQ4FPNW1HH0O47B1i3JW00Lke2m2POg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
=D0=92 Sat, 17 Nov 2012 15:00:06 -0500 grarpamp <grarpamp@gmail.com> =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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121117221143.41c29ba2>