Re: [Gnu-arch-users] GNU Arch review - am I accurate?

[Andrew Suffield]

On Wed, Mar 03, 2004 at 07:07:09AM +0000, David A. Wheeler wrote:
> Hi - I've been trying to understand various SCM tools
> (primarily CVS, Subversion, and Arch), and
> ended up putting my thoughts down in an article:
>  http://www.dwheeler.com/essays/scm.html
> I list a number of problems/issues I have with tla's
> current implementation, but I'm obviously not an arch
> guru, so please send me corrections where I've made mistakes.

These all look like pretty minor things, really. I've certainly seen
longer lists of objectionable things about cvs and svn, and I expect
bk has plenty of its own. I find cvs revision numbers and svn urls to
be beyond a joke.

To pick on a few points at random:

> The mirroring capability is clever, but if you download a mirror and
> make a change, you can't commit the change and the tool isn't smart
> enough to help.

I can't see that there's anything it could or should do. tag, then
commit - it's not complicated. Using undo here is a daft idea.

> Arch will sometimes allow dangerous or problematic operations that
> just shouldn't be allowed. For example, branches should be either
> commit-based branches (all revisions after base-0 are created by
> commit) or tag-based branches (all revisions are created by tag);
> merging commands will not work otherwise, yet the tool doesn't
> enforce this limitation.

I've seen this one floating around as hearsay for a while now. I don't
believe any such limitation exists. Seems to work for me. You rarely
*want* to do it, though.

> The recommended GNU arch setup for a central repository has all
> users sharing a single account

Who's been recommending that? The recommended setup is to not use
"central repositories". Use properly distributed archives. If you
think you want a "repository", we've heard it all before, you don't.

You focus on problems caused by this scenario a fair bit - but it's
not a scenario you should be going anywhere near. You do not want to
do things that way.

> The signatures sign the revision number as well as the change itself
> (they're both encoded in the signed tarball), so an attacker can't
> just change the patch order and can't silently remove a patch and
> renumber the later patches without detection. However, it appears to
> me that such signatures (at least as currently implemented) cannot
> detect the malicious substitution of whole signed patches (such as
> the silent replacement of a previous security fix with a non-fix),
> or removal of the "latest" fix before anyone else uses it.

This problem is not specific to arch. It's a fundamental limitation of
cryptographic signatures. There is no way that you can ever tell
whether you are looking at the latest copy of the tree, or whether
you're looking at a snapshot that a hostile interloper took yesterday
and has substituted for the new one. I don't believe it is even
theoretically possible to solve this problem in any system that is
based on signatures.

You've picked up the random noise about MD5 being weaker than
SHA-1. If MD5 had any significant weaknesses, today, you would be
completely and totally fucked. You would not be worrying about
signatures on arch archives; you would have more pressing security
issues. Lots of things rely on the security of MD5, which is one of
the most long-lived algorithms in cryptography. It has no known
weaknesses in practical use and should last another 10 years or so
before it needs to be retired. If you're just being paranoid then you
should note that the NSA is moving to retire SHA-1, so it's not
exactly a good choice for a paranoid replacement, and trusting the NSA
that much is probably a dumb idea anyway - it's not like they haven't
kept techniques for attacking encryption schemes secret for decades
before now.


Nothing to do with arch, but Haskell isn't slow. It's one of the
fastest compiled languages around; the ghc optimiser is probably the
single most effective optimiser out of *any* language (Haskell is
particularly easy to optimise well). darcs is slow because, well,
darcs is slow. Changing the language wouldn't affect that, although
changing the algorithms probably would.

> There are some things I didn't see:
> * Is anyone currently working on automated caching?

Does anybody even care? I've never had a use for it.

> * Has anyone thought about the "signing of signing" issue
>   (A signs A's code, B accepts it, C accepts B's, and we
>   have a chain of signatures from all 3 showing the transition)?
>   Centralized systems don't need this as much, but distributed
>   systems need more if you're going to show where code came from.

The data's there already. If you *ever* want to know *anything* about
a changeset that is not in its patch log then you need a copy of the
relevant branch from the archive it came from - mirror as
necessary. Archives are small, so this is cheap. Since you want to
know where code came from, you need the contents of the original
changesets, so you need a mirror of the archive. It's simple to retain
the original signatures in the mirror.

Then you just have to follow the chain back. There's no tool to do
this yet because nobody's wanted one, and I don't think anybody has a
good idea what it should output anyway. Maybe you want viewarch to
show signatures or something, I can't really guess.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature