On Fri, Apr 09, 2010 at 03:36:10PM +0100, Philip Martin wrote:
> Tim Starling <tstarling_at_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.9040506@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.camel@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
Received on 2010-04-09 22:52:31 CEST