[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: authz changes between 1.9 and 1.10

From: Branko Čibej <brane_at_apache.org>
Date: Wed, 25 Jul 2018 13:15:52 +0200

On 25.07.2018 08:21, Daniel Shahaf wrote:
> Philip Martin wrote on Tue, 24 Jul 2018 23:37 +0100:
>> Branko Čibej <brane_at_apache.org> writes:
>>> It describes designed behaviour. If we change it, we should do it
>>> carefully, as I wrote above. Also I think it turns out that the authz
>>> section in the release notes misses a behaviour change or two. It should
>>> probably include the whole Inheritance and Disambiguation list, however
>>> we end up changing it.
>> The most important thing is to document the change in behaviour of the
>> non-glob rules between 1.9 and 1.10.
>>
> +1; we should document any incompatible changes (regardless of whether
> they were intentional or not).
>
>> The problem I have is that I still don't know if the changes are
>> intentional. Of these undocumented (in the release notes) changes there
>> is one that appears to be intentional and two that could be accidental.
>> At least the first, intentional, change produces a run-time error if it
>> occurs, the other two just lead to different access being granted, one
>> less access the other more access. Anyone using a non-trivial authz
>> file in 1.9 has to be very careful upgrading to 1.10.
>>
> Sounds like we should encourage people to write unit tests for their
> authz files. This would be fairly easy to implement using 'svnauthz
> accessof'. We could ship something in tools/ that takes two
> inputs, an authz file and a set of expectations, and validates the authz
> file against the expectations.

I think serious admins already do this :) But sure, if someone has the
time and inclination to write such tools, they'll surely be useful.

-- Brane
Received on 2018-07-25 13:16:01 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.