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

[David A. Wheeler]

Andrew Suffield said:
> > 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.

But if you've acquired stuff from a mirror, as long as the mirror
is up-to-date there's no reason that commit should cause a problem.
Tla should be able to find the 'real' archive and commit instead.

My evidence is at:
http://wiki.gnuarch.org/moin.cgi/Arch_20Recipes#head-2c5332402d44ef87a1bb8d4fdf2ccaf758a57334

Where it says:
"Say for example that you tla get a source tree from an archive mirror, and 
start
hacking on it. After you have made a bunch of changes, you realise that you 
cannot
commit the changes back, as the originating archive was a mirror. You really 
should
have created a new branch to commit the changes on. You can use the command tla
undo to revert the tree back to its original revision, and save the changeset.
You can then move this changeset elsewhere, make a branch (or whatever fixup is
required). Then you use the tla redo command to reapply the changes to the
new source tree, after which you can commit."


> > 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. ...

But:
http://www.gnu.org/software/gnu-arch/tutorial/symbolic-tags.html#Symbolic_Tags

Says:
"Usage Caution: As a rule of thumb, your 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 ).
Commands such as replay , update , and star-merge  are based on the
presumption that you stick to that rule. While it can be tempting,
in obscure circumstances, to mix commit  and tag  on a single branch --
it isn't generally recommended."

When documents say "critical commands presume that X is true",
I'm hardly eager to risk doing it.  Either it works or it doesn't.
If the documentation is wrong, the docs need to be fixed.
If it "usually" works, except sometimes it corrupts your project,
let's just say I'm not interested :-).

While I loathe arbitrary limitations of any kind, sometimes they're
unavoidable.  In these cases, though, the tool should prevent the
dangerous action and explain why.

> > 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.

It's all in the "how to" section for centralized development:
 http://wiki.gnuarch.org/moin.cgi/Centralized_20Development

 
> 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.

Sometimes I do, sometimes I don't.  But MOST development projects
_DO_ use a centralized repository, and there ARE good reasons for it.
If nothing else, many people DO want them.

Besides, GNU Arch actually can support this approach fairly well, given the
caveats.  I want a tool that's flexible enough to handle many different
approaches, for the many projects I deal with.  You may not think
it's a good idea, but a vast number of people do; why not do it well?


> > 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.

Actually, this one is relatively easy to handle.  Here's one
approach that I think would work.  Basically, you
have a separate signature for the "chain".  Each entry has, as well as
a hash, a "cumulative hash" - a hash of (this-hash + previous-cumulative-hash).
Now, sign both hashes.

The "deleted endpoint" can be handled by ensuring that the folks
who deposited the endpoint do checks, and send out alerts.

Improvements, etc., welcome.
 
> You've picked up the random noise about MD5 being weaker than SHA-1.

There's already been an old published paper showing very significant
weaknesses in MD5 -- not enough to break it completely, but enough
to be worried.  Since then, there have been persistent rumors
inside the crypto community that the algorithm has been broken, and
those rumors are hard to ignore because MD5 was hanging by a thread anyway.

Let's see, we have two alternative algorithms, SHA-1 and MD5, that we're
depending on for its crypto properties.  MD5 is known to have a partial break,
with significant rumors of a complete break.  SHA-1 has no such problem.
SHA-1 is slightly slower, but not significantly so.

It seems to me that the best approach is pretty clear -
don't use MD5 for new code. It's hard to switch old stuff, but there's
no need to embed it in new stuff.

I've been sent separate email that there's already a waiting patch
to add SHA-1 support for arch.  I think that's excellent.

> 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).

Color me skeptical.  Haskell uses lots of optimizations, because truly
functional programming languages require lots of optimizations to be
even marginally useful.  I'd like to see the evidence on real-scale
programs (ones that include I/O, etc.).  Actually, I'd be delighted if
that's the case, can you point me to some?  It's been a while since I've
looked at FP, and I'm certainly willing to believe things have
changed since then.

> darcs is slow because, well,
> darcs is slow. Changing the language wouldn't affect that, although
> changing the algorithms probably would.

Hehe.  Many programs can be described that way.

Anyway, thanks very much for the feedback.

--- David A. Wheeler