On 14.12.2018 22:55, Doug Robinson wrote:
> Brane:
>
> I've decided that documenting the syntax of authz files at this level
>> doesn't really belong in this document. So I started this:
>>
>> https://cwiki.apache.org/confluence/x/oYvQBQ
>>
>> and will refer to that page instead, pointing out the d
Brane:
I've decided that documenting the syntax of authz files at this level
> doesn't really belong in this document. So I started this:
>
> https://cwiki.apache.org/confluence/x/oYvQBQ
>
> and will refer to that page instead, pointing out the differences.
>
The statement "Section names are case
On 05.12.2018 15:23, Branko Čibej wrote:
> On 05.12.2018 15:05, Julian Foad wrote:
>> Branko Čibej wrote:
>>> On 05.12.2018 14:44, Julian Foad wrote:
Branko Čibej wrote:
> Yes, but I'm asking for a review of the BNF to make sure that it doesn't
> contain silly bugs.
At first glanc
On 05.12.2018 15:05, Julian Foad wrote:
> Branko Čibej wrote:
>> On 05.12.2018 14:44, Julian Foad wrote:
>>> Branko Čibej wrote:
Yes, but I'm asking for a review of the BNF to make sure that it doesn't
contain silly bugs.
>>> At first glance, I saw what looks like a bug: it says a comment
Branko Čibej wrote:
> On 05.12.2018 14:44, Julian Foad wrote:
> > Branko Čibej wrote:
> >> Yes, but I'm asking for a review of the BNF to make sure that it doesn't
> >> contain silly bugs.
> > At first glance, I saw what looks like a bug: it says a comment must have a
> > non-white-space immediate
On 05.12.2018 14:59, Branko Čibej wrote:
> On 05.12.2018 14:44, Julian Foad wrote:
>> Branko Čibej wrote:
>>> Yes, but I'm asking for a review of the BNF to make sure that it doesn't
>>> contain silly bugs.
>> At first glance, I saw what looks like a bug: it says a comment must have a
>> non-white
On 05.12.2018 14:44, Julian Foad wrote:
> Branko Čibej wrote:
>> Yes, but I'm asking for a review of the BNF to make sure that it doesn't
>> contain silly bugs.
> At first glance, I saw what looks like a bug: it says a comment must have a
> non-white-space immediately after the '#'... I didn't rev
Branko Čibej wrote:
> Yes, but I'm asking for a review of the BNF to make sure that it doesn't
> contain silly bugs.
At first glance, I saw what looks like a bug: it says a comment must have a
non-white-space immediately after the '#'... I didn't review further.
--
- Julian
On 05.12.2018 14:27, Julian Foad wrote:
> Branko Čibej wrote:
>>> https://cwiki.apache.org/confluence/x/7IjQBQ
>> It is starting to improve. I'll be grateful to anyone who cares to take
>> a look to debug the syntax BNF.
> I appreciate the right-bracket rule change is in that domain.
>
> Could I ne
On 05.12.2018 14:27, Julian Foad wrote:
> Branko Čibej wrote:
>>> https://cwiki.apache.org/confluence/x/7IjQBQ
>> It is starting to improve. I'll be grateful to anyone who cares to take
>> a look to debug the syntax BNF.
> I appreciate the right-bracket rule change is in that domain.
>
> Could I ne
Branko Čibej wrote:
>> https://cwiki.apache.org/confluence/x/7IjQBQ
>
> It is starting to improve. I'll be grateful to anyone who cares to take
> a look to debug the syntax BNF.
I appreciate the right-bracket rule change is in that domain.
Could I nevertheless encourage you to jump ahead to writ
On 02.12.2018 17:28, Branko Čibej wrote:
> On 02.12.2018 16:49, Branko Čibej wrote:
> Seriously though: I started this document
> https://cwiki.apache.org/confluence/x/7IjQBQ
> Yes, it's empty. It will improve.
It is starting to improve. I'll be grateful to anyone who cares to take
a look to debu
On 02.12.2018 16:49, Branko Čibej wrote:
> On 02.12.2018 15:15, Julian Foad wrote:
>> Branko Čibej wrote:
>>> I have a patch ready, here are some examples of what it does [...]
>> Not following the details, all I would ask ("all", he says) is that a
>> complete description of the new semantics be
On 02.12.2018 10:38, Branko Čibej wrote:
> On 02.12.2018 08:43, Branko Čibej wrote:
>> On 02.12.2018 08:25, Branko Čibej wrote:
>>> On 08.09.2018 11:17, Stefan Fuhrmann wrote:
These are the guiding principles for the 1.10 authz design:
(1) ACLs are only evaluated on a per-user bases;
On 02.12.2018 15:15, Julian Foad wrote:
> Branko Čibej wrote:
>> I have a patch ready, here are some examples of what it does [...]
> Not following the details, all I would ask ("all", he says) is that a
> complete description of the new semantics be available for review, and should
> be publishe
Branko Čibej wrote:
> I have a patch ready, here are some examples of what it does [...]
Not following the details, all I would ask ("all", he says) is that a complete
description of the new semantics be available for review, and should be
published along with the changes. Otherwise I fear the c
On 02.12.2018 08:43, Branko Čibej wrote:
> On 02.12.2018 08:25, Branko Čibej wrote:
>> On 08.09.2018 11:17, Stefan Fuhrmann wrote:
>>> These are the guiding principles for the 1.10 authz design:
>>>
>>> (1) ACLs are only evaluated on a per-user bases; ACLs that
>>> don't mention this user (or a
On 02.12.2018 08:25, Branko Čibej wrote:
> On 08.09.2018 11:17, Stefan Fuhrmann wrote:
>> These are the guiding principles for the 1.10 authz design:
>>
>> (1) ACLs are only evaluated on a per-user bases; ACLs that
>> don't mention this user (or any of their groups) are ignored.
>> Rationa
On 08.09.2018 11:17, Stefan Fuhrmann wrote:
> These are the guiding principles for the 1.10 authz design:
>
> (1) ACLs are only evaluated on a per-user bases; ACLs that
> don't mention this user (or any of their groups) are ignored.
> Rationale: We don't want to explicitly repeat inherited
Most of these issues have already been addressed by Brane,
but as he wished for my input, here it is.
These are the guiding principles for the 1.10 authz design:
(1) ACLs are only evaluated on a per-user bases; ACLs that
don't mention this user (or any of their groups) are ignored.
Rati
On 30.07.2018 14:51, Philip Martin wrote:
> Daniel Shahaf writes:
>
>> Branko Čibej wrote on Mon, 30 Jul 2018 03:07 +0200:
>>> It's definitely better to have consistent behaviour across all rule
>>> types.
>> +1
> I like the idea of achieving consistency by making the duplicate entries
> into an e
Philip Martin wrote on Mon, Jul 30, 2018 at 13:51:06 +0100:
> @@ -820,6 +833,13 @@ add_access_entry(ctor_baton_t *cb, svn_stringbuf_t
>
>SVN_ERR_ASSERT(acl != NULL);
>
> + if (svn_hash_gets(cb->rule_entries, name))
> +return svn_error_createf(SVN_ERR_AUTHZ_INVALID_CONFIG, NULL,
> +
Daniel Shahaf writes:
> Branko Čibej wrote on Mon, 30 Jul 2018 03:07 +0200:
>> It's definitely better to have consistent behaviour across all rule
>> types.
>
> +1
I like the idea of achieving consistency by making the duplicate entries
into an error: it changes the behaviour of 1.10 but anyone
Branko Čibej wrote on Mon, 30 Jul 2018 03:07 +0200:
> On 30.07.2018 02:38, Philip Martin wrote:
> > Branko Čibej 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 necessar
On 30.07.2018 02:38, Philip Martin wrote:
> Branko Čibej 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" ru
Branko Čibej 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
>
On 25.07.2018 08:21, Daniel Shahaf wrote:
> Philip Martin wrote on Tue, 24 Jul 2018 23:37 +0100:
>> Branko Čibej 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
On 25.07.2018 00:37, Philip Martin wrote:
> Branko Čibej writes:
>
>> On 20.07.2018 14:59, Philip Martin wrote:
>>> In 1.9 it was possible to repeat, or reopen, a section:
>> It's an intentional change that is documented in the design wiki page.
> And only there, it didn't make the release notes.
Philip Martin wrote on Tue, 24 Jul 2018 23:37 +0100:
> Branko Čibej 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
>
Branko Čibej writes:
> On 20.07.2018 14:59, Philip Martin wrote:
>> In 1.9 it was possible to repeat, or reopen, a section:
>
> It's an intentional change that is documented in the design wiki page.
And only there, it didn't make the release notes.
>> In 1.9 any repeat acl lines that were the e
On 20.07.2018 14:59, Philip Martin wrote:
> In 1.9 it was possible to repeat, or reopen, a section:
>
> [/some/path]
> user = r
> [/some/path]
> otheruser = rw
>
> This was equivalent to a single section:
>
> [/some/path]
> user = r
> otheruser = rw
>
> In 1.10 this is rejected by the
In 1.9 it was possible to repeat, or reopen, a section:
[/some/path]
user = r
[/some/path]
otheruser = rw
This was equivalent to a single section:
[/some/path]
user = r
otheruser = rw
In 1.10 this is rejected by the parser and cannot be used. Is this a
bug in 1.10 or an acceptabl
32 matches
Mail list logo
