Re: [Gnu-arch-users] .listing files

[Tom Lord]

    > From: Robert Collins <address@hidden>

    > On Sun, 2004-09-19 at 22:42 -0400, James Blackwell wrote:
    > > Ok then. My quick straw poll comes up with "one guy against, everyone
    > > else for". I happen to be for it myself.

    > > Jivera, Rob, Tom, (anybody else I missed), any opinions?=20

    > > I'm going to work up a patch for this tonight, but there's still plenty
    > > of time to discuss this. I'm not planning on releasing 1.2.3rc1 until 8
    > > Oct. If there's any reasonable objections prior to that point, I'm fine
    > > with pulling it.

    > I'm against it: .listing files have cache coherency problems, non-ACID
    > properties & generally should die (but cannot due to the non-ubiquitous
    > nature of webdav).

    > I'm not cognisant of Tom's 'security issues' stuff, but IMO the above is
    > enough to keep .listing as optional, not recommended, and therefore not
    > default.

You just named the essense of my 'security issues'.

The unavoidable, undesirable properties you named are the indirect
consequence of relying on http when, really, a dumb fs transport is
called for.   It works well enough "out of the box" that I don't
expect people to run into lots of problems with it on non-critical
set-ups, but at the same time, a "best practices" http set-up requires
additional configuration, outside of arch, to protect the integrity of
.listing files.

What's the specific exploit?  Who knows!?  Who cares!?  Certainly a
naive deployment of .listing files can lead to rare but nasty
accidents and that fact is sufficient to prove that the risk of
exploits is too great.

Also: when I say "security issue", I don't mean *only* exploits.
Accidents with security consequences are security issues as well and 
I think you can see that naively deployed .listing files can certainly
lead to accidents that can have security implications.

As with the asynchronous-detached-star-merge-leading-to-crossed-merges 
issue, the manual would benefit from a nice loud cartouche around a
warning that references a few pages on how to handle .listing files in
critical systems.   

By making .listings the default we would be steering new admins away
from the documentation and encouraging them to skim, set up something
that appears to work, and forget about it.

In summary, as you and others have noted, .listings are a hack that
allows a substandard transport to be used for archives, but the hack
has costs.   Failure to note and pay those extra costs injects a
little flakiness into set-ups.   Injecting flakiness into default
set-ups is not something that should be done.

-t