httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: [PROPOSAL] Move httpd to the subversion repository
Date Wed, 17 Mar 2004 10:39:10 GMT
Justin Erenkrantz wrote:

> --On Tuesday, March 16, 2004 8:19 PM +0000 Ben Laurie 
> <ben@algroup.co.uk> wrote:
> 
>> c) You appear to be assuming daily snapshots maintained forever in your
>> story - if so, how do you deal with network problems and the like? How
>> can you tell a commit that didn't make it to the "secure" server because
>> of a network problem from one that the attacker injected?
> 
> 
> I think you're misunderstanding here.  After every commit, an 
> incremental backup containing that revision is generated.  It'd then be 
> copied over to a 'backup' site.  There is no reason to re-dump the 
> repository every day as that'd be just too big.  If a commit is 'missed' 
> due to an attack or whatnot, it'd be obvious because that particular 
> revision number will not appear.
> 
> This is not like CVS where the prior history can be directly modified by 
> tweaking the RCS files.  For CVS, there is no concept of incrementality 
> - the RCS files just aren't stable enough.
> 
> I'd suggest seeing minotaur:/x1/svn/hot-backups for an idea as to what 
> we're doing right now.  (We have yet to digitally sign anything though.)

I'm guessing I need subversion to check that out, right? (This is a good 
example of what Dirk is talking about, and I'm not even on an old system 
- I'd install subversion from ports, except my ports are out-of-date, 
and I leave for a trip tomorrow, so I don't want to update them and 
break my machine just before I go).

>> In the solution you've rather vaguely outlined, after a server compromise
>> I find myself checking a bunch of commits signed by the compromised
>> server and then making some other vague assumptions I'm not sure I
>> understand to convince myself that they were pre-compromise signatures. I
>> don't feel like my security has been improved. Possibly a clearer
>> explanation is all that is required, or maybe a rethink. I can't tell at
>> this stage.
> 
> I think you're missing that the incrementality causes us to believe the 
> pre-compromise signatures (as the backup can be done in such a way not 
> to modify already existing files).  Remember, everything is uniquely 
> ordered in Subversion.  If you also don't trust a hot backup, you can 
> also burn those dumps to a 'permanent' media like a DVD-R to later 
> verify it.  But, once revision 1 is committed, that's revision 1 forever 
> - it's immutable once it's in the repository.  If it *has* changed, 
> that's evidence of a compromise.  -- justin

OK, I think I can believe this can work, but it needs to be carefully 
documented and implemented so we don't find that when it comes to it 
we've missed some small detail (for example, you don't want the remote 
backups to have the same date as the local ones - you want them to have 
the date they were transferred).

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Mime
View raw message