[Box Backup] Help installing client on Mac OS X

[Peter Jalajas, TebucoSafe Backups]

X-Stamper-To: boxbackup@fluffy.co.uk

Hi James,

--- James O'Gorman <james@netinertia.co.uk> wrote:

> On Mon, Oct 08, 2007 at 02:10:06PM -0700, Peter Jalajas, TebucoSafe Backups wrote:
> > So implementing a strategy of security as a risk-management onion, and knowing that nothing is
> > ever perfectly secure, the Box Backup project could/should take reasonably aggressive measures
> to
> > use the available convenient processes that help ensure (assure?) the security of the source
> code
> > and binaries.  Maybe you all do already, and I just haven't bother to track it all down.  
> 
> Apart from anything, I have the Box Backup sources stored within Box
> Backup :-) The entire svn and trac data is part of my Box store, so I'd
> say that's pretty safe. If, god forbid, this server was compromised, we
> have fully-encrypted backups. I think Ben takes offsite backups too.

Yes, definitely.  That is an "availability" factor, where we could recover if we were compromised,
_and noticed it_.  What I was thinking, but couldn't yet verbalize, was something like this, maybe
a code "chain of custody" kind of thing.  

1.  The security architecture of Box Backup was analyzed and the results published and openly
discussed.  For example, one section might say, "Box Backup contains no crypto code and instead
uses freely available open-source external crypto libraries including openssl installed on the
host system.  You can find the code using the openssl libraries in these Box Backup source code
files..."

2.  The source code files are written, and at various milestones automatically hashed (and maybe
signed) and the hashes published as widely as conveniently.  This could be just a single hash of
the milestone tarball.  The user could simply Google the hash of his copy of the tarball, and
should be able to see that same hash on multiple servers (bbdev.fluffy.co.uk, google, my server,
others' servers, http://www.itconsult.co.uk/stamper.htm?, http://copyclaim.com?, etc.), providing
reasonably good verification, helping us detect if Box Backup has been compromised. (Signing the
tarball would maybe provide better security, but maybe at a bit more cost to everyone, I think
worth it, but I'll let those that have to do it decide.)

3.  For packaged binaries, the builders could then also perform and publish some kind of
build-environment verification (source code, compiler tools, config files, output binaries, etc)
to help us end-users trust the package. (http://sourceforge.net/projects/tripwire/ comes to mind.)
 This part, I know, is a lot of work, and of limited security value, but some reasonably
aggressive level of it should be done, IMHO, and over time, the security value of it all should
increase, I'm guessing (right now we have nothing).  To paraphrase Chris, whom should the
potential Box Backup users out there trust?  We can help more end-users trust us, and Box Backup,
by providing some more security-related information.  I'm open to edification and suggestions.

> > So, yes, having widely disseminated sha1sums of everything goes a very long way towards that
> end
> > with very little pain, I think.  Signatures go yet again a bit further, but with a little more
> > pain.  (Insert other heavier lifting here.)  You hosting a keysigning party in Cambs is
> probably
> > too aggressive and inconvenient, providing too little bang for the buck, as we say here.  ;^)
> > 
> > In a previous life as a Release Engineering manager for an enterprise security product, I
> appended
> > to our software build process an immediate automatic wide-dissemination of md5sums (md5 was
> state
> > of the art then, as I believe sha1 is now) of all individual source files, binaries, tarballs,
> 
> Most people/projects are skipping SHA-1 and using SHA-256 now. (FreeBSD
> used to just do md5sums of third-party distfiles in ports, now it does
> md5sum and sha256.)

Wow, I just did a bunch of googling on the hash matter. 
http://en.wikipedia.org/wiki/Cryptographic_hash . RIPEMD-160, SHA-512, Whirlpool, Tiger, egads. 
Based on what I've read this morning, sha1 should be fine for our purposes, but again, I'll leave
that to the folks that have to do that work.  Again, say what we do, do what we say, document it,
and let the end-user decide.  

For the record, for example, to start the process, my fairly up-to-date and default Ubuntu has:

pj@b:~/download$ dpkg -l | grep openssl
ii  openssl                                0.9.8c-4ubuntu0.1                      Secure Socket
Layer (SSL) binary and related

which yields, presuming rmd160 is the strongest hash that I have already installed:

pj@b:~/download$ openssl rmd160 boxbackup* 
RIPEMD160(boxbackup-0.10_plus_chris_merge_1792.tgz)= e78f0288c8eb6ff14da7bc2d283a33e2c885f019
RIPEMD160(boxbackup-chris_general_1280-backup-client-mingw32.zip)=
58cec843115dc309bbf3d078deca0ea8a3e6a215
RIPEMD160(boxbackup-chris_general_1516-backup-client-mingw32.zip)=
fec1062d9cddafe0220d86bc1e82d357b3b8c3bf
RIPEMD160(boxbackup-chris_general_1569-backup-client-mingw32.zip)=
0cdae189f69974a9612433af8e62cb5e99c57207
RIPEMD160(boxbackup-chris_general_1857-backup-client-mingw32.zip)=
bb541e1ac1b9b0500261093f439ed48f07d1908a

What I'm saying is that eventually Chris' 1857 build with a rmd160 of
bb541e1ac1b9b0500261093f439ed48f07d1908a should acquire a reputation, good or bad.  But with a
very commonly available and simple command, we all know that we are talking about the exact same
package.  Google will soon pick up that number and spread it around. 

Phew.

Thanks again, James,
Pete