Hacker News new | past | comments | ask | show | jobs | submit login

Lacking cryptographic hashes used by most DVCS software, SVN repositories need some external mechanism to be pretty sure the source repository hasn't been compromised. For instance, one might have snapshots of the SVN tree taken every week.

It's much easier with git or hg, even in the single-master-repo model, even if all developers are using the CVS gateway so they don't have local copies of commit history. All such a project would need in order to protect against compromise (ignoring physical redundancy) is a backup git or hg repo, kept offline except for periodic pulls. As long as there are no warnings about upstream rebases, and you trust all visible commits, then everything's fine[1].

With SVN, as long as there's no built-in cryptographically secure way to connect one snapshot to the next when backing up SVN repos, determining the existence of a backdoor requires comparing entire backup SVN repos against the live main repo. Even if sufficient backups exist, the process is slow and requires taking the main SVN repo offline if there's any chance of a root compromise.

[1] Caveat 1: in any RCS, there could be backdoors masquerading as legitimate-looking commits if the attacker had commit access. Caveat 2: The security is subject to the cryptographic security of SHA-1.

In this FreeBSD case, if they're certain the svn repo wasn't compromised, all they have to do is validate the checkout on the two compromised machines against the svn repo.




This is kind of silly. They can simply diff to find changes. All the developers have several checkouts.

There are lots of things that are great about git, but it's not a security cure-all.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: