Skip site navigation (1)Skip section navigation (2)
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>