freebsd security - Nov 2012 - FreeBSD needs Git to ensure repo integrity [was: 2012 incident]

http://www.freebsd.org/news/2012-compromise.html
http://it.slashdot.org/story/12/11/17/143219/freebsd-project-discloses-security-breach-via-stolen-ssh-key

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.

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.

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.

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.

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.

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...

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.

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.

https://www.kernel.org/pub/software/scm/git/docs/git-fsck.html
 Verifies the connectivity and validity of the objects in the database

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.

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.

Some references...
 http://git-scm.com/
 https://github.com/
 http://gitweb.dragonflybsd.org/dragonfly.git
 https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git

? Sat, 17 Nov 2012 15:00:06 -0500
grarpamp <grarpamp at gmail.com> ?????:
> http://www.freebsd.org/news/2012-compromise.html
>
http://it.slashdot.org/story/12/11/17/143219/freebsd-project-discloses-security-breach-via-stolen-ssh-key
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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...
> 
> 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.
> 
> 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.
> 
> https://www.kernel.org/pub/software/scm/git/docs/git-fsck.html
>  Verifies the connectivity and validity of the objects in the database
> 
> 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.
> 
> 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.
> 
> Some references...
>  http://git-scm.com/
>  https://github.com/
>  http://gitweb.dragonflybsd.org/dragonfly.git
>  https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git
LOL And how will this help Linux?
http://lwn.net/Articles/457142/

[snip]

There's a git repository. It's public. You can look at what goes into
the FreeBSD git clone to get your assurance that things aren't being
snuck in. People are using it, right now.

Honestly, I'd rather see subversion grow this kind of cryptographic
signing of each commit in the short term then migrate everyone over to
git.

Those who want to use git can use it, right now. Honest.



Adrian

On Sat, Nov 17, 2012 at 11:55 PM, Adrian Chadd <adrian at freebsd.org>
wrote:
> Those who want to use git can use it, right now. Honest.
Yup:
https://github.com/freebsd/

19.11.2012 14:34, Ivan Voras wrote:
> On 17/11/2012 22:48, Chris Rees wrote:
>
>> (and is GPL btw)
>
> Since we're discussing it, Mercurial is BSDL-ed, and apparently has
> proper crypto signing using GPG:
>
>
http://mercurial.selenic.com/wiki/FAQ#FAQ.2FTechnicalDetails.How_do_Mercurial_hashes_get_calculated.3F
:%s/BSD/LGP/

http://mercurial.selenic.com/about/

-- 
Sphinx of black quartz, judge my vow.

On Mon, Nov 19, 2012 at 4:34 AM, Ivan Voras <ivoras at freebsd.org> wrote:
> On 17/11/2012 22:48, Chris Rees wrote:
>
> > (and is GPL btw)
>
> Since we're discussing it, Mercurial is BSDL-ed, and apparently has
> proper crypto signing using GPG:
>
>
>
http://mercurial.selenic.com/wiki/FAQ#FAQ.2FTechnicalDetails.How_do_Mercurial_hashes_get_calculated.3F
>
>
>
http://selenic.com/repo/hg/file/fd903f89e42b
http://selenic.com/repo/hg/file/fd903f89e42b/COPYING
"
GNU GENERAL PUBLIC LICENSE
  <http://selenic.com/repo/hg/file/fd903f89e42b/COPYING#l2>Version 2, June
1991

 <http://selenic.com/repo/hg/file/fd903f89e42b/COPYING#l3>
"

In their repository , it is GPL v2 .

Is there any other place which specifies its license as BSDL ?


Thank you very much .

Mehmet Erol Sanliturk

grarpamp <grarpamp at gmail.com> writes:
> Any of hundreds of committer and admin accounts could be compromised
> with the attacker silently editing the repo.
FUD.  Committer accounts don't have direct access to the repo.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no