[Box Backup] Help installing client on Mac OS X

Peter Jalajas, TebucoSafe Backups boxbackup@fluffy.co.uk
Mon, 8 Oct 2007 14:10:06 -0700 (PDT)

Hi Chris,

Great points all, as always!  

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.  

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,
etc, so that anyone (developers, testers, sales, app engineers, customers) had the _ability_ to
_very conveniently_ _know_ that they had the correct files.  For sure, that information was mostly
ignored, but when it was needed, it proved very much worth the little additional effort expended. 

I can't recall if I also published the md5sums of the build tools, too, but that would add another
layer to the security onion.  What steps do package builders typically use these days to lock down
their build environments to ensure that they aren't sending out malware?  

Derived from an interesting page re ISO 9000 http://c2.com/cgi/wiki?WikiPagesAboutSayWhatYouDo : 

    * Say What You Do (Have Documented Security Procedures)
    * Do What You Say (Follow the Procedures)
    * Record What You Did (Widely Publish Security-Relevant Records to a Separate Google-Crawled
Mailing List, perhaps via http://www.itconsult.co.uk/stamper.htm)

(I wonder if a shared Amazon EC2 server, or a public build site like SourceForge, could be put to
good use in this regard?)

I didn't win the lottery for the Led Zeppelin benefit concert at O2, so we'll have to postpone the
keysigning party.  

Thanks again, Chris, and everyone else!

--- Chris Wilson <chris@qwirx.com> wrote:

> I'm not sure that downloading and installing a binary package is any 
> different to downloading, compiling and installing a source package, 
> UNLESS you take the time to verify the sources by hand.
> Assuming that you don't (and I don't, even though I know I should :-) then 
> it comes down to taking packages (binary or source) only from those who 
> you trust. Leading to the question, "who do you trust"? Which is one that 
> I'd be very interested to hear your answers on :-)
> E.g. would you trust a package (binary or source) from Fink? From Debian 
> (Reinhard Tartler)? From Per Thomsen? From me? From Ben? What would your 
> customers trust?
> Would you trust a source or binary package based on trunk less than an 
> official release with known bugs and a well-known MD5sum?
> Would you trust a Microsoft patch with a license agreement that allows 
> them to install arbitrary software on your machine at a later date? Would 
> you still trust Microsoft after they installed that arbitrary software 
> without telling you?
> Would you trust a (source or binary) release more if it had a published 
> MD5 checksum? If it had a PGP signature? Can you actually verify stuff 
> against my PGP key? Do you trust that it was really me who uploaded that 
> key? Would you trust my emails more if I PGP-signed them?
> In my view it comes down to an element of unknown risk (of bugs more than 
> trojans) from running newer, less tested code, versus an element of 
> (better) known risk running older code with known bugs (which might also 
> be trojaned). And also the reputation of the code authors, the 
> maintainers, the packagers and the distributors.
> Personally I put near-absolute trust in my distro maintainers and the 
> packages that they choose to release (and whether those packages are 
> destined to run with root privileges or not) because I feel they they have 
> more to lose by being publicly humiliated than I do by running their code.
> As far as Box is concerned, I trust James to keep our Subversion server 
> safe, and I trust Subversion to send me commit logs, which I read to 
> ensure that nothing happens to the Box source without me knowing about it 
> and understanding what it does (as best this bear of little brain can 
> understand anything).
> So what do "security gap", faith and trust mean for you? I guess we need 
> better definitions of those terms. At least I do before I can even try to 
> assuage your doubts.
> Cheers, Chris.
> -- 
> _____ __     _
> \  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
> / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
> \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |
> _______________________________________________
> boxbackup mailing list
> boxbackup@fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup