directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Custine" <ccust...@apache.org>
Subject Re: [Kerberos] PKINIT support
Date Sun, 23 Sep 2007 17:43:32 GMT
On 9/23/07, David Jencks <david_jencks@yahoo.com> wrote:
>
> dunno alex. but this strikes me as a bit strange for you to be criticizing
> Enrique for thinking about adding new features whereas for the last month
> you were too busy adding new features to review a pretty simple code cleanup
> patch.
>

I'll take the blame for this one.  I volunteered to make sure this was
addressed but the 1.5.1 release,  LDAPCon trip, and some client work have
gotten in the way for the last few weeks.

I'm also a bit unclear exactly what you mean by "I'm just going to say no
> for now".  To me this looks like a proactive veto of code that hasn't even
> been written yet, without a technical justification.  I don't quite see how
> that fits into normal apache procedures.  What am I missing?
> I thought one of the ways to make an open source project flourish was to
> encourage people to contribute what they want and can contribute.  I think
> that telling people their work is not welcome is likely to keep the
> contributor base, well, extremely manageable.
>
> Personally I think this is looks like a nice bit, not that i understand
> any deep details about it, and if my voice meant anything i'd encourage
> Enrique to work on it.  If he wants to write more docs than he already has
> on some other bits he's contributed that would be fine with me too, but I
> usually find that docs are wrong by the time they are actually written and
> available.  I generally find clear code is a better bet.
>

I think the PKINIT feature sounds very cool indeed, but I agree with Alex
and Emmanuel that we must be careful not to have too many individually
contributed features that we can't properly support as a community.  I have
noticed that we have had several embarrassing cases where we basically had
to defer support of certain features like this.  Along those same lines, I
think we are trying to take this project from a sandbox toy to being a more
serious option in the directory services world and part of that involves
things that a lot of people don't like to focus on such as documentation,
extensive test coverage, performance tuning, and usability considerations.
New features are a lot more fun, but we get far more complaints about lack
of docs, bugs, and performance issues than we get requests for new
features.


BTW, where are the developer and user guides for the dynamic schem stuff?
> I'm probably just not looking in the right place but I haven't been able to
> find the docs on how to use this feature.
>
> And finally, what are
> http://directory.apache.org/apacheds/1.5/dns-protocol-provider.html
> http://directory.apache.org/apacheds/1.5/dns-protocol-configuration.html
> which I found in the advanced user guide table of contents?
>
> I hope I'm not burning too many bridges with this email but I can't say I
> have any desire to work on a project that features responses like this to
> proposals for cool new stuff.
>

I haven't been around long enough to be familiar with the history brought up
here, but if there is a problem with lack of tests for certain features then
I think the concerns are perfectly valid.  My personal opinion is no tests,
no commit (unless strictly sandbox code of course).

So that is all just my 2 cents and nothing more.


thanks
> david jencks
>

Cheers,
Chris

On Sep 23, 2007, at 12:11 AM, Alex Karasulu wrote:
>
> IMO if you have some time you might want to start work on some developer
> documentation
> on DNS as well as a user's guide so we can attract more committers while
> answering user
> questions around DNS.
>
> Just this week someone asked about this on the users list and all they
> heard were crickets.
> Emmanuel had to sit there and tell the guy that we cannot support him and
> its an embarrassment
> for us.  He had to apologize for your actions. That's not cool.
>
> Although I want to see you make strides on adding new features to Kerberos
> I think it's a bit irresponsible
> for you to get back into new features without documenting others that you
> added in the past.
> You just can't do that while you leave the DNS situation in a poor state.
> Do you understand
> the point I'm trying to make here?  Do you see some merit in what I am
> saying from a community
> perspective? I'm trying to get you to understand where we're coming from
> and not think this is
> at all any means to lessen your value.  We really like the technical
> things you do but a community
> is not just about the code.
>
> It's antithetical to OS culture to just drop code or features into some
> project and leave.  You have
> to take care of the users, the developers that come after you so the
> project is alive rather than being
> an inanimate piece of code.  By suggesting this new feature addition
> before taking care of your
> inherent responsibilities to the community clearly shows that you're not
> thinking about these aspects.
> This is why I'm going to just say no for now.
>
> Secondly with respect to technical matters how does this impact what we
> have in Triplesec
> with HOTP?  Is this another SAM type for the kerberos server which uses
> the class loading
> scheme we already have in place for verifiers?
>
> Alex
>
>
> On 9/22/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
> >
> > Hi, Directory developers,
> >
> > I have a window with no major deadlines for the next few weeks, so I
> > looked into adding 1 new Kerberos feature for the next release.  After
> > doing some "due diligence," ie reading the relevant specs and
> > reviewing what support I need from the JDK and various libraries, I am
> > highly confident I can add PKINIT support for 1.5.2.
> >
> > PKINIT is a pre-authentication type for Kerberos (detailed in RFC
> > 4556).  For those not familiar, PKINIT can be quickly summarized as
> > "smartcard authentication for Kerberos, replacing the
> > username/password."  PKINIT can also work with a local keypair, so
> > there isn't a requirement for hardware like an actual smartcard,
> > though that is the intended deployment scenario.
> >
> > Since this is only a new pre-authentication verifier, I would rather
> > not branch and instead develop this, at first, in my sandbox.  I have
> > time starting this weekend, so I'd like to start to get code
> > committed, to back the code up.
> >
> > Enrique
> >
>
>
>

Mime
View raw message