Re: Pushmi support

[Philip Martin <ph...@wandisco.com>]

Tim Starling <ts...@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,
particularly for something that could be a security issue.

[...]
> 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.

-- 
Philip

RE: Pushmi support

["Bolstridge, Andrew" <an...@intergraph.com>]

> -----Original Message-----
> From: hyrum@hyrumwright.org [mailto:hyrum@hyrumwright.org] On Behalf
Of
> Hyrum K. Wright
> Sent: Friday, April 09, 2010 9:58 PM
> To: Stefan Sperling
> Cc: Philip Martin; Tim Starling; Greg Stein; Subversion Development
> Subject: Re: Pushmi support
> 
> The last thing I want to do is add more process (someones earlier
> comments
> about HACKING are quick illuminating), but it might be worth creating
a
> template for such a document and posting it somewhere.  I don't think
we
> need to go the full route of PEPs, but having some way to track design
> proposals with more finesse than the issue tracker would be nice.

Collabnet's TeamForge?

Re: Pushmi support

[Greg Stein <gs...@gmail.com>]

On Fri, Apr 9, 2010 at 16:58, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>
> On Fri, Apr 9, 2010 at 9:51 PM, Stefan Sperling <st...@elego.de> wrote:
>>
>> 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
>
> The last thing I want to do is add more process (someones earlier comments
> about HACKING are quick illuminating), but it might be worth creating a
> template for such a document and posting it somewhere.  I don't think we
> need to go the full route of PEPs, but having some way to track design
> proposals with more finesse than the issue tracker would be nice.

This is why patches are nice. Already have the format!


But yah... if it is going to be a lot of work, then discussion is at
least warranted. That's the best way to get a feeling for whether the
effort will be worth it.

In this case, I think the question "should I bother to work on this?"
was probably left hanging because the problem/solution was too vague
for people to definitively answer.

Cheers,
-g

Re: Pushmi support

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

On Fri, Apr 9, 2010 at 9:51 PM, Stefan Sperling <st...@elego.de> wrote:

> 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
>

The last thing I want to do is add more process (someones earlier comments
about HACKING are quick illuminating), but it might be worth creating a
template for such a document and posting it somewhere.  I don't think we
need to go the full route of PEPs, but having some way to track design
proposals with more finesse than the issue tracker would be nice.

-Hyrum

Re: Pushmi support

[Stefan Sperling <st...@elego.de>]

On Fri, Apr 09, 2010 at 03:36:10PM +0100, Philip Martin wrote:
> Tim Starling <ts...@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