Alistair Crooks wrote:
> On Sat, Jun 23, 2007 at 06:23:44PM +0300, Elad Efrat wrote:
>> I don't understand how kauth not being maintained means it's okay to
>> expose its internals.
> 
> If kauth is not being maintained, why are you bothering to copy the
> world and its dog on your email?
> 
> I know it's much easier to stand on the sidelines and shout whenever
> anyone touches a file with the letters "kauth" anywhere in its name,
> but it's not getting you or the project any further along the road.

what are you attacking here? me or the points I brought up? I think
the former. I cc "the world and its dog" because the commits in
question have the potential to affect the world and its dog. it is a
simple matter of responsibility.

> If you care about kauth, agree to the same rules that every other
> developer does, and maintain it. 

what rules do I not agree to? :)

> If you don't, it will bitrot, and
> will have to be thrown out. And, as I said, that would be a pity.

throw it out then. it's better to not ship it at all than to ship it
broken.

>> question to you, al, as a core member and tnf president: will it be
>> as easy as it was to implement various security models on top of kauth
>> now that its internals have been exposed?
> 
> As a software developer, my answer to your question would be "no - if
> the complete abstraction has been violated, then it will be harder to
> build models on top of kauth". Has the complete abstraction been violated,
> or just a part of it? 

part of it. luckily enough, I managed to revert the commit that
completely violated the abstraction. this time it's only part of it, but
does it really matter? if it's not 100% opaque it just means it's not
100% broken.

> Where is the documentation dealing with the
> abstractions 

kauth(9),

>, the ways it fits into other kernel code, 

kauth(9) and secmodel(9) and see xrefs on the latter,

> and the direction
> forward for kauth?

in the archives of developers@ from about a year ago where I laid
out the plan for netbsd 5.0.

> As President of TNF and a member of the core team, I would ask that
> you consider that it might be more fun for you if you were a part of
> the project.  You can't change anything if you're not part of it - the
> best that you could hope for is to stand around on the sidelines and
> say "I wouldn't have done it like that."

okay then, here are two commits:

http://mail-index.netbsd.org/source-changes/2007/02/09/0010.html

this breaks kauth opacity, okay'd by core.

http://mail-index.netbsd.org/source-changes/2007/02/24/0026.html

this reverts the above, requested by core.

can you explain to the people who are cc'd to this message how come
that core approved and then disapproved of the same change? can you
also comment on whether or not I pointed this is flawed before and
right after it was committed? can you also explain why my technical
opinion was ignored, even though I was still a developer, and was
accepted only after I removed myself from the list of developers?

>> does "compat code with one less malloc" weighs more than "opaque and
>> abstract interface allowing various pluggable secmodels"?
>>
>> to users: the commit in question means that the internals of kauth have
>> been exposed, severely limiting the flexibility of the interface. if it
>> was possible to say "kauth allows different secmodels to be implemented
>> and used in netbsd", after the commit it means "back to stone age".
> 
> You shouldn't say things like that - it just gives ammunition to the
> people who are nervous about kauth, who are concerned by its lack of
> documentation, 

nice try.

kauth(9) and secmodel(9) are probably the more verbose and clear man
pages netbsd has. every modification to these was discussed publicly,
and there are code examples both in the source tree and in the man pages
themselves. my plans for the short term were also discussed publicly,
and my plans for the long term were published on a developers-only list
because I didn't feel like being obligated to so many things.

furthermore, only one person told me he found the documentation of kauth
lacking -- in the area of how to use certain functions in the context of
drivers. he told me that in person, and I fixed the documentation
shortly after.

given the above, can you please point out:

   - what type of documentation is missing regarding kauth?
   - why didn't you let me know about it a lot earlier if it's that
     critical?
   - what do you consider a properly documented kernel interface?
   - where is the documentation for the kauth interface changes
     introduced by dsl@?

> the fact that there is no one maintaining it, or,
> worse, driving it, and who want to replace it with (a clone of)
> Apple's kauth, which has had many more eyes on it.

you should be aware then that:

   - netbsd can't make use of apple's code without asking permission
     first to change the kauth license,

   - netbsd's kauth implementation is much more robust than apple's,
     and falling back to apple's means netbsd can *not* support pluggable
     security models,

   - the missing parts in the netbsd implementation are missing because
     netbsd lacks the required underlying interfaces. "missing parts" are
     the fileop and vnode scopes, and I challenge you to implement them,

   - apple's kauth doesn't have dsl@'s added functionality,

   - it's very likely that more eyes, not to say more "qualified" eyes,
     gone through netbsd's kauth than apple's kauth.

...and since you're talking about eyeballing - how many people reviewed
the commits in question? :)

-e.