> On Dec 13, 2018, at 11:26 AM, Branko Čibej <brane_at_apache.org> wrote:
>
> On 13.12.2018 17:09, Mark Phippard wrote:
>>> On Dec 13, 2018, at 10:53 AM, Michael Pilato <cmpilato_at_collab.net> wrote:
>>>
>>>> On 12/13/18 10:45 AM, Branko Čibej wrote:
>>>> Uh. I forgot about the malfunction handler. However this doesn't really
>>>> help, other than putting possibly sensitive paths into the crash handler
>>>> info? We really shouldn't do it this way, users *will* just copy and
>>>> paste the output tot he 'net.
>>> Ahem. What Grandpa *meant* to say was:
>>>
>>> "Oh, cool! So there _is_ a way to report the non-canonical path.
>>> Thanks for figuring this out, Julian! Unfortunately, it comes at a
>>> cost, namely that of revealing potentially sensitive paths in the output
>>> which I strongly suspect will get copied and paste to the 'net. If we
>>> could mitigate that part of it, this might turn out to be truly beneficial."
>>>
>>> ;-)
>> Honestly, it seems like complete FUD to me and trying to save face or just be obstinate.
>>
>> FWIW, I agree with Stefan on all of this. We should not be doing abort from a library. Whether TSVN could do more to avoid it seems like a separate issue. I do not see why the library cannot just return a useful error and allow the caller to handle it.
>
>
> Backwards compat dictates that we can't change the signatures of those
> functions. We can write new ones with different signatures and deprecate
> the old ones.
>
>
> Or rather "they" because I'm not volunteering for the code churn and
> related backporting fallout. That's not stopping anyone else from having
> a go.
>
Fair enough. I have largely stayed out of the conversation for the same reason ... I am not offering to help with the effort.
It is good to hear you are not necessarily opposed to someone doing this work because I was under the impression you would try to block those changes.
Mark
Received on 2018-12-13 17:40:07 CET