[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: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Mon, 30 Jul 2018 05:50:44 +0000

Branko ─îibej wrote on Mon, 30 Jul 2018 03:07 +0200:
> On 30.07.2018 02:38, Philip Martin wrote:
> > Branko ─îibej <brane_at_apache.org> writes:
> >
> >> It's worth working on a fix, IMO. My suggestion would be:
> >>
> >> * Keep the single-rule behaviour as it turned up in 1.10, just
> >> document it. It's necessary for glob rules and making an exception
> >> for "old-style" rules will limit the ways we can improve the authz
> >> system in future. Also it'd make the next point quite a bit harder.
> > Agreed. It is a regression from 1.9 but it's a hard error so it will
> > not change behaviour silently.
> >
> >> * Change the ACE override/merge behaviour back to the 1.9 way, as
> >> there's no reason I can think of that it could be either.
> > I have a patch to do this. At present I am distinguishing between glob
> > and non-glob rules and only apply the 1.9 way to non-glob rules. This
> > means that a 1.9 authz file retains the 1.9 behaviour, and that the 1.10
> > glob rules retain the the 1.10 behaviour for anyone who has started
> > using them. But is also means glob and non-glob rules behave
> > differently.
> >
> > Is it better to preserve as much 1.10 behaviour as possible because
> > people may have started using it, or is is better to have consistency
> > between glob and non-glob rules?
> It's definitely better to have consistent behaviour across all rule
> types.


> Otherwise there'll be no end of user questions about it ... and
> we'll keep second-guessing ourselves, too. Also imagine this:
> [:glob:/path]
> foo = rw
> foo = r


- The 1.9 behaviour is reasonable: it follows a simple rule (the same
  one our CLI --option=argument parsing uses, and our
  ~/.subversion/config files parsing too, I believe), so an admin might
  have reasonably assumed it to be intentional. It _is_ a feature of Subversion
  that all ConfigParser-ish config files are parsed the same way, after all.

- 1.10 makes an incompatible change to the 1.9 semantics. The change
  is undocumented in the release notes, so a 1.9 admin can't be
  expected to be aware of the change, but _is_ documented in the design
  wiki, so a 1.10 admin may have seen it in the design wiki and started
  to rely on it.

We effectively made two contradictory compatibility promises; we can't
honour both of them. I think our only option is to make it a syntax error.

"In the face of ambiguity, refuse the temptation to guess."



P.S. I _would_ have had this discussion during the design phase if I had
     noticed the issue back then. Sorry to have missed it.
Received on 2018-07-30 07:51: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.