This bug was reported on 2010-12-11.  We've done some diagnostics, 
created some preliminary patches and are now ready to roll out a 
release.  The bug appears to relatively minor in practice, so after some 
discussion, we've decided to just put the patch on the tracker.

It seems like we're not being aggressive enough in checking for 
malicious subpaths in darcs repositories.  One could (eg. by 
manipulating patch bundles or local darcs executables) create 
repositories that refer to paths outside of the repo.  The reporter gave 
us a nice minimal test (attached) which creates a file /tmp/test.txt if 
you get a malicious repository.

I think we know what we need to do to solve this in the long term -- 
tear out our subpath representation and switch to something like Petr's 
components-based representation in pathlib.  

In the medium term, it may also be good for us to fix hashed-storage 
(I'll post some patches to the current branch later).

We also have a patch which seems to solve the immediate problem in the 
short term.  I'm concerned that said patch is a bit band-aid-
y/plasterish.  Hopefully discussion on the list will help us work out if 
this is the appropriate solution for 2.5.1.

Eric Kow <bugs@darcs.net> writes:
> I think we know what we need to do to solve this in the long term -- 
> tear out our subpath representation and switch to something like Petr's 
> components-based representation in pathlib.  
>
> In the medium term, it may also be good for us to fix hashed-storage 
> (I'll post some patches to the current branch later).

I think in recent (pathlib-based) incarnations of hashed-storage (and
fslib, the to-be-successor) this is fixed. You may be kicked out of your
program by an exception when you try to construct a relative path (not a
sub path) with a Sub type, though.

Yours,
  Petr

The following patch updated issue issue2035 with status=resolved;resolvedin=2.5.1 CURRENT

* Resolve issue2035: Catch malicious subpaths. 
Ignore-this: a6800c388c8c4390a92005496d6628e3
A longer-term fix would be to change our subpath representation
to be components based (eg. like pathlib)

The following patch sent by Eric Kow <kowey@darcs.net> updated issue issue2035 with
status=resolved;resolvedin=2.8.0 HEAD

* Resolve issue2035: Catch malicious subpaths. 
Ignore-this: a6800c388c8c4390a92005496d6628e3
A longer-term fix would be to change our subpath representation
to be components based (eg. like pathlib)