directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [Kerberos] PKINIT support
Date Sat, 29 Sep 2007 00:29:42 GMT
There's a really loooong juiced discussion going right now on the Tomcat developer list (The
subject is: "Re: Review model take 2" )wrt this type of stuff (Veto criteria, sandbox vs.
trunk, etc.).  I suspect that the results and reasons for the results would apply to all apache
projects, so it might something good to draw on as a sort of "Case Study".  Just mentioning
it as it might be a useful reference point down the line.  

- Ole

David Jencks wrote:
> I've had some discussions with Alex and Emmanuel and it's become clear 
> to me that I let a combination of my own frustrations and lack of 
> knowledge of the history here run away and lead me to making some 
> unfortunate statements.
> IIUC the underlying situation here is that most of the apacheds 
> community has an informal criterion for code being in trunk and released 
> -- that more that one person can support the code.  This could be from 
> several people working on it, general familiarity with it, or through 
> javadoc, documentation, and examples.  Through some historical accidents 
> there is some code in the server that doesn't really meet this criterion 
> very well and there's some confusion about what to do about it and how 
> to keep the problem from getting worse.
> I believe one step that has been taken is to suggest that new code that 
> may not immediately be OK be developed in a sandbox or branch until 
> enough people feel it can be well supported at which time it can be 
> moved into trunk.  I think this is a great idea because it provides a 
> simple process solution to what was starting to appear to be a personal 
> clash.  ("all defects are process defects")  I think it might be a good 
> idea to have a "production ready sandbox" where working code that needs 
> documentation or review can sit and gain documentation and comments 
> until enough people agree that its supportable.  It might be advisable 
> to move some code out of the server to here.
> I don't think there's been an overwhelming amount of discussion about 
> this process on the dev list so I'm hoping that if I'm right about this 
> process we'll hear more about it and that it will be documented 
> somewhere on the project web site.  And if I jumped to yet more 
> unjustified conclusions I look forward to hearing about them as well :-)
> thanks
> david jencks
> On Sep 22, 2007, at 11:14 PM, David Jencks 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'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.
>> 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 
>> 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.
>> thanks
>> david jencks
>> 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* < 
>>> <>> 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

View raw message