[darcs-users] suggestion: each push should identify its target repo internally

John Meacham john at repetae.net
Thu Aug 14 00:54:28 UTC 2003


On Wed, Aug 13, 2003 at 05:33:51PM -0700, Zack Brown wrote:
> Something else just occurred to me - assuming darcs always looks for the
> GNUPG keys in _darcs, then there should be no risk at all in letting the
> user push with a URL, or a relative path name.
> 
> As long as darcs confirms that (a) the URL or path name points to a repository,
> and (b) the push is properly signed by someone with permission to push,
> then it doesn't matter what the path is. The path either leads to a
> repository that provides access to that user or it doesn't. End of
> story.
> 
> So, just to recap. The procmail recipe is something like
> 
> :0:
> * ^DarcsURL:
> | darcs apply -r
> 
> An email comes into the system with a URL or path name in the "DarcsURL"
> field. the email is piped to darcs. If DarcsURL has a URL, then darcs reads
> the web server config files to find the mapping to a path. If DarcsURL just
> has a path, darcs uses that. Once the path is known, darcs checks there
> to see if it's a valid repo. If so, it checks _darcs for the allowed_keys
> file, and verifies the signature of the push. If the signature is invalid,
> darcs abandons the push, and no harm done. If the signature is valid, darcs
> completes the 'apply' and sends out appropriate emails.
> 
> So if this makes sense, then the main thing under contention is how
> darcs determines the mapping from URL to directory path. I think using
> the web server config files is a good way because it's non-redundant,
> but there are arguments to be made for other ideas. Regardless of how
> that mapping ultimately gets done, does the rest of this make sense?

in a perfect world without bugs this might be true, but what if a bug is
found in darcs? or gnupg? basic security concerns say you should never
do anything on external input which isn't explicitly allowed. what if
you copy a repository somewhene to develop privatly and forget to remove
the allowed_keys or it finds the incorrect apache config files. 

Parsing the apache configuration files would be the wrong thing to do.
it is a  needless dependency and complication. I want to explicitly
specify my Url -> repo mapping and have it reject any patches outright
which don't have an allowed url without trying to process them further.
All entry points into my computer via darcs from the unknown wilds of
the internet should be enumerated in one place, not determined by an odd
interaction of apache config files procmail scripts and key files
distributed across repositories. plus I don't even use apache
everywhere. and when I do, I don't even have access to the config files.
for instance, I accept patches on my local machine and apply changes to
my repository here, but they are actually exported to the web by a
different machine which I do not have access to but shares an NFS mount
with me.

besides, if one really wants, they could easily write a little perl script
which automatically generated the appropriate (url, path, keys) entries
from apache configs and keylists in the repository. 

It is just good software design to make darcs as generic and simple as
possible and build infrastructure on top of it for dealing with specific
configurations.

        John

-- 
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - john at foo.net
---------------------------------------------------------------------------




More information about the darcs-users mailing list