On 19.01.2019 22:24, Branko Čibej wrote: > On 18.01.2019 23:07, Doug Robinson wrote: >> Honored committers (and the rest of us): >> >> It's come to my attention that if a group is defined in an AuthZ >> file without an associated account that SVN is, as of 1.10, generating >> an error and failing to allow the use of that AuthZ file. >> >> Example: >> >> [groups] >> goodGroup = acct1 >> goodGroup2 = acct1, acct2 >> badGroup = >> >> [repoName:/someplace] >> @badGroup = rw >> >> svnauthz: E220003: Error while parsing authz file: ... >> svnauthz: E220003: Access entry refers to undefined group ... > > Thinking about this some more: If we add a warning callback to the > parser (I have that implemented locally), we may as well relax the > requirement for a group being /defined/, not just non-empty. For > example, this authz file will also fail to parse with the same error as > shown above: > > [/] > @nosuchgroup = rw > > > and this one will also complain about an undefined group, but with a > different message: > > [groups] > somegroup = @nosuchgroup > > > In both cases, instead of exiting with an error, just ignoring the ACE > or group membership wouldn't affect the semantics of the authz file. If > we can print warnings about such issues in 'svnauthz', users would still > have a way to find such bugs in their authz files. > > Relaxing the restrictions on undefined groups (and maybe aliases, too?) > would be a change for the next minor release. > > Thoughts?
If we're going to change the public API of the authz parser, we could also add an equivalent of a -Werror flag to svnauthz. That could be useful for scripts so that warnings don't get ignored. We could also add such a flag to the parser itself, but I'm not sure how such a thing could be used at the repository level. -- Brane
