FreeBSD needs Git to ensure repo integrity [was: 2012 incident]

[Polytropon]

On Sun, 18 Nov 2012 00:59:54 -0500, grarpamp wrote:
> > Never trust an operating system you don't have sources for. ;-)
> 
> As well summarized by this (your signature) ... sources you can't
> verify to the master are, also, sources you can't trust.

Unless. of couse, you are able to "use the source Luke" and
spot malicious portions by yourself. This of course is usually
possible to subsets only, and mostly to the gurus of our guild.
The "ordinary user" won't be able to do this.



> >> fidaj at ukr.net
> > LOL And how will this help Linux?
> > http://lwn.net/Articles/457142/
> 
> How will what help Linux? Please quote a relevant snippet instead
> of the entire message.
> 
> Seems pretty clear from the above link that having hashes/crypto
> as an intrinsic feature of the SCM tool does in fact help Linux.

The article's headline is "kernel.org compromised", and the
significant part (as of August 2011!) is:

	Earlier this month, a number of servers in the kernel.org
	infrastructure were compromised. We discovered this August
	28th. While we currently believe that the source code
	repositories were unaffected, we are in the process of
	verifying this and taking steps to enhance security across
	the kernel.org infrastructure.

However, this is a Linux problem, not a FreeBSD one, regarding
repository infrastructure.



> >> utisoft at gmail.com
> > Yes, but git doesn't work with our workflow.
> 
> There's usually a larger than head sized sandbox near everyone's
> local neighborhood. Will people elect to visit it, or to learn,
> grow, and change for the better?

In many contexts, "better" _depends_.



> Prioe workflow is often forced by
> and derived from the tools being used.

That is _one_ (valid!) way to see it. Another way is that tools
will be chosen according to established workflows, or tools will
adapt those workflows to better support them.



> Different tools could enable
> different, more useful workflows. SVN required workflow change from
> CVS, people managed just fine.

If the required programs will be integrated in the OS, accompanied
by proper documentation, and the backend infrastructures being
instantiated, up and running, I don't see a big problem. Unlike
in other "OS countries", FreeBSD people are able to adapt to new
methods and tools.



> > [git] ... is GPL btw
> 
> FreeBSD does not include this sort-of-BSD licensed SCM tool in its
> base either...
> 
> # https://svn.apache.org/repos/asf/subversion/trunk/LICENSE
> # ls /*bin/svn /usr/*bin/svn
> ls: No such file or directory
> 
> But it does include this GPL licensed one...
> 
> # http://cvs.savannah.gnu.org/viewvc/cvs/ccvs/COPYING?revision=HEAD
> # ls /*bin/cvs /usr/*bin/cvs'
> /usr/bin/cvs
> 
> And of course we have this in use as well...
> 
> # perforce
> http://www.perforce.com/purchase/pricing-licensing
> 
> So it seems license is not an obstacle to inclusion, and certainly
> not the use via ports, of any particular SCM with the FreeBSD
> project.

As far as I know, FreeBSD team puts much work into getting the
OS into a "BSD license only" state, making it more appealing to
commercial use where the (often so called) "rape me license"
BSDL is very welcome.

But as for "being part of the OS installation", you are right:
Whatever tool will be required (or at least suggested) for the
purpose of managing "CVS-like" functionality for sources and
the ports collection should be part of the basic installation.
That's why "pkg_add -r cvsup-without-gui" (if I remember correctly)
has been the way in the past, but then, a rewrite called csup
became part of the default installation, so you could use the
known cvs command _and_ have a nice integration with system
functionality, like entries in /etc/make.conf and configuration
files for _how_ to update sources, ports, documentation and
so on (e. g. in /etc/sup, with /usr/share/examples/cvsup/ as
examples), so "make update" would do whatever you wanted.
Exactly that kind of productive (!) behaviour is what I would
expect (or at least wish) for any replacement of CVS, be it
SVN or Git.



> Sorry to reply to these sorts of replies this way, but please, this
> isn't a troll or a shed. No need to do that around the issue raised.
> Hash [ :-) ] it out and solve it.

With some salt, please. :-)





-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...