On Fri, Apr 09, 2010 at 03:36:10PM +0100, Philip Martin wrote: > Tim Starling <tstarl...@wikimedia.org> writes: > > > That was my fourth post to this list, I was referring to the other > > three, particularly: > > > > <http://mail-archives.apache.org/mod_mbox/subversion-dev/201003.mbox/%3c4baa79df.9040...@wikimedia.org%3e> > > > > I could see that after being ignored on that issue, my only chance of > > being heard would be to get to know the developers and then to take a > > more personal approach. That's why I stayed on this list. Unfortunately > > I haven't had much time to read it. > > You were not exactly ignored, but asking for in-principle approval > before submitting a patch is not the way the project usually works,
We do encourage people to write design proposals before writing patches. > particularly for something that could be a security issue. Well, since we're well aware of the security implications (Greg Hudons explains them well in http://mail-archives.apache.org/mod_mbox/subversion-dev/201003.mbox/%3c1269433056.7493.527.ca...@ray%3e ) I'd say this isn't a problem. We just need to make sure to make it secure by default. I don't see a problem in principle with providing an optional mechanism for users like Tim to pass credential information via selected environment variables (like SSH_AUTH_SOCK) to tools called by hook scripts. > > could be corrected with a patch to Subversion, possibly as short as a > > few lines of code. I'm offerring to write the patch. > > Writing the patch would be a way forward. Or writing a design proposal, that clearly explains the intent of the change, the reason why it's needed, the security implications, how exactly the change will be implemented (e.g. where will the config setting live that allows the new behaviour?), etc. Something that helps people with loading the entire problem into their brain quickly, so they can reason about it. Stefan
