You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Enrique Rodriguez <en...@gmail.com> on 2007/09/23 02:47:25 UTC
[Kerberos] PKINIT support
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
Re: [Kerberos] PKINIT support
Posted by Alex Karasulu <ak...@apache.org>.
On 9/23/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 9/22/07, Alex Karasulu <ak...@apache.org> 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.
> > ...
>
> Point taken. I will prioritize this higher than new features, such as
> PKINIT or StartTLS.
StartTLS is fine for you to work on since we can support that code - the
code already
exists anyway and just needs a clean up and placement into the project.
The problem lies in code bases which we cannot support as a team and
that's the whole point to this. So don't get the wrong idea that people
don't want you to add new things. It's just we don't want you to add new
things that we cannot support as a team.
Let's not sway onto the opposite end of the spectrum either.
> ...
> > 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?
>
> My plan is to make pre-auth verifiers "pluggable" in the same way that
> core Authenticators can be configured via Spring XML. I am committed
> to supporting Triplesec such that the HOTP verifier works after this
> configuration change. Though, since last I checked, Triplesec builds
> against a 1.0, this is moot until Triplesec moves to the next stable
> branch.
I think Christine made it build now with 1.5 just recently.
Alex
Re: [Kerberos] PKINIT support
Posted by Enrique Rodriguez <en...@gmail.com>.
On 9/22/07, Alex Karasulu <ak...@apache.org> 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.
> ...
Point taken. I will prioritize this higher than new features, such as
PKINIT or StartTLS.
> ...
> 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?
My plan is to make pre-auth verifiers "pluggable" in the same way that
core Authenticators can be configured via Spring XML. I am committed
to supporting Triplesec such that the HOTP verifier works after this
configuration change. Though, since last I checked, Triplesec builds
against a 1.0, this is moot until Triplesec moves to the next stable
branch.
The class loading scheme only allows one plug-in. This
configuration/plugin change is separate from PKINIT, which would use
this "plugin point" just like HOTP will.
PKINIT is not another SAM type. PKINIT has its own base RFC with its
own pre-auth type.
Enrique
Re: Documentation on dynamic schema updates (was Re: [Kerberos] PKINIT support)
Posted by Alex Karasulu <ak...@apache.org>.
Thanks for the update Stefan. At least this shows the intent to document
and support a feature
even though it may not be perfect. The most important point is there are
people here who do work
on this stuff and users will be taken care of with potentially several
responses to their questions
from those who can guide them.
This did not happen overnight or by itself - the community formed because
there was diligence
around meeting this need. There was intention and an effort was made.
Alex
On 9/24/07, Stefan Zoerner <st...@labeo.de> wrote:
>
> David Jencks wrote:
> ...
>
> > 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.
>
> Just in case, somebody reads this and concludes that we do not have any
> documentation on dynamic schema updates etc.
>
> At least we have a detailed step-by-step guide for novice users who plan
> to add their own elements to the schema -- either programmatically or
> with the help of Directory Studio.
>
>
> http://directory.apache.org/apacheds/1.5/add-your-first-elements-to-the-schema.html
>
> And yes, it is neither complete nor perfect, especially when it comes to
> advanced topics.
>
> Greetings,
> Stefan
>
>
Documentation on dynamic schema updates (was Re: [Kerberos] PKINIT
support)
Posted by Stefan Zoerner <st...@labeo.de>.
David Jencks wrote:
...
> 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.
Just in case, somebody reads this and concludes that we do not have any
documentation on dynamic schema updates etc.
At least we have a detailed step-by-step guide for novice users who plan
to add their own elements to the schema -- either programmatically or
with the help of Directory Studio.
http://directory.apache.org/apacheds/1.5/add-your-first-elements-to-the-schema.html
And yes, it is neither complete nor perfect, especially when it comes to
advanced topics.
Greetings,
Stefan
Re: [Kerberos] PKINIT support
Posted by Chris Custine <cc...@apache.org>.
On 9/23/07, David Jencks <da...@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 <en...@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
> >
>
>
>
Re: [Kerberos] PKINIT support
Posted by Emmanuel Lecharny <el...@gmail.com>.
Ok, I get it :
EncryptedData ::= SEQUENCE {
etype [0] Int32 -- EncryptionType --,
kvno [1] UInt32 OPTIONAL,
cipher [2] OCTET STRING -- ciphertext
}
This is the ASN.1 grammar found in the RFC. The EnryptedData class use
cypher, not cyphertext, to reflect the grammar, but the following code
:
...
// build the ciphertext structure
byte[] conFounder = getRandomBytes( getConfounderLength() );
byte[] dataBytes = concatenateBytes( conFounder, plainText );
byte[] checksumBytes = calculateIntegrity( dataBytes,
key.getKeyValue(), usage );
byte[] encryptedData = encrypt( dataBytes, Ke );
byte[] cipherText = concatenateBytes( encryptedData, checksumBytes );
...
use the cipherText, possibly because of the commented name in the
ASN.1 grammar, and because it's the result of the cipher algorithm.
Even if it's not semantically correct, I think it's important to stick
to the RFC naming because then it's easier for new comers to switch
from RFC to the code and back.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [Kerberos] PKINIT support
Posted by Emmanuel Lecharny <el...@gmail.com>.
> I looked it over. The first thing is a nitpick of the change you made
> from "cipher text" to "cipher." A cipher is an algorithm, while
> cipher text is the output. Why the ASN.1 for EncryptedData calls this
> "cipher" I don't know, but they clarify in the ASN.1 notes (RFC 4120
> 5.2.9) that this field contains "ciphertext."
Can you point me to the code ?
>
> Enrique
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [Kerberos] PKINIT support
Posted by Enrique Rodriguez <en...@gmail.com>.
On 9/24/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> ...
> Feel free to have a look at it, it's far from being perfect nor
> finished. It's just a work in progress I wanted to share. Would you
> have any question or suggestion about it, please do so. I will be
> please to answer.
I looked it over. The first thing is a nitpick of the change you made
from "cipher text" to "cipher." A cipher is an algorithm, while
cipher text is the output. Why the ASN.1 for EncryptedData calls this
"cipher" I don't know, but they clarify in the ASN.1 notes (RFC 4120
5.2.9) that this field contains "ciphertext."
Enrique
Re: [Kerberos] PKINIT support
Posted by Emmanuel Lecharny <el...@gmail.com>.
Thanks Enrique.
FYI, I have just committed all the changes I have made on kerberos
code this summer in a branch :
https://svn.apache.org/repos/asf/directory/apacheds/branches/trunk-wd-kerberos
Feel free to have a look at it, it's far from being perfect nor
finished. It's just a work in progress I wanted to share. Would you
have any question or suggestion about it, please do so. I will be
please to answer.
Emmanuel
On 9/24/07, Enrique Rodriguez <en...@gmail.com> wrote:
> On 9/23/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > ...
> > Sandbox can be used to push this kind of new code, I see no problem.
> > When it reaches a level of tests which allow any other committer to
> > anter into it, and do some modification without breaking the tests,
> > then it can be added to the project.
> > <chair hat off>
>
> After clarifying this point with Emm via IM, I understand I can make
> PKINIT commits to a new module in my personal sandbox and that, at
> such time as the team is comfortable with the level of tests and doco,
> that a further decision can be made to move it to the trunk.
>
> Enrique
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [Kerberos] PKINIT support
Posted by Alex Karasulu <ak...@apache.org>.
On 9/23/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 9/23/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > ...
> > Sandbox can be used to push this kind of new code, I see no problem.
> > When it reaches a level of tests which allow any other committer to
> > anter into it, and do some modification without breaking the tests,
> > then it can be added to the project.
> > <chair hat off>
>
> After clarifying this point with Emm via IM, I understand I can make
> PKINIT commits to a new module in my personal sandbox and that, at
> such time as the team is comfortable with the level of tests and doco,
> that a further decision can be made to move it to the trunk.
>
That's just fine.
Alex
Re: [Kerberos] PKINIT support
Posted by Enrique Rodriguez <en...@gmail.com>.
On 9/23/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> ...
> Sandbox can be used to push this kind of new code, I see no problem.
> When it reaches a level of tests which allow any other committer to
> anter into it, and do some modification without breaking the tests,
> then it can be added to the project.
> <chair hat off>
After clarifying this point with Emm via IM, I understand I can make
PKINIT commits to a new module in my personal sandbox and that, at
such time as the team is comfortable with the level of tests and doco,
that a further decision can be made to move it to the trunk.
Enrique
Re: [Kerberos] PKINIT support
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hey, guys, please, please, cool down !!!!
There are things which are important, and things which are not.
I have nothing against PKINIT inclusion into the code, but at some
point, we also have to consider the community around the project
itself. Pushing some new code is *good*. But we must also support the
users, and we also have to be around when a new committer/user tries
to use it.
We have had some concerns about the kerberos code at the beginning of
the year, because there was no documentation at all (and the situation
is slightly better), and also absolutly no tests.
Lacks of Documentaion seems to be a common disease, so I won't blame
people for not pushing perfect docos, as we are all faulty.
Lacks of tests is damn bad, because not only we have no clue about
what is doing the code, but also we are stuck with the existing code
base without any way to guarantee that a modification will not break
the whole stuff.
Lacks of test and lacks of javadoc is even more evil.
David, i'm sorry, but I have to back Alex on that, for the reasons I
just pushed. Before adding some new code to a stack of 15Klocs nobody
but Enrique has a clue about is really not an urgent thing. I would
prefer that Enrique spend some time he has on improving the tests on
the existing code base.
<chair hat on>
I would like to say that it's utterly important for the project to
have simple rules at this point :
- adding new code is _good_
- code without tests, javadoc, documentation is _bad_
- adding some new code to an existing stack of not documented,
javadoced and with no tests is not something that will help the
project.
It's not about doco, it's about tests. With tests, everyone of us can
play with the code. Without tests, the code deserves to be sandboxed.
Sandbox can be used to push this kind of new code, I see no problem.
When it reaches a level of tests which allow any other committer to
anter into it, and do some modification without breaking the tests,
then it can be added to the project.
<chair hat off>
In my mind, and for having worked on Kerberos code base in the last 3
months, PKINIT implementation and maybe the whole kerberos project
should be moved to the sandbox, except that we have a need for
kerberos into trunk. And it's also the reason why In have spent days
on kerberos this summer : to avoid a one man show situation.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [Kerberos] PKINIT support
Posted by Ole Ersoy <ol...@gmail.com>.
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.
Cheers,
- 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
>> 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.
>>
>> 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* <enriquer9@gmail.com
>>> <ma...@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
>>>
>>>
>>
>
Re: [Kerberos] PKINIT support
Posted by Alex Karasulu <ak...@apache.org>.
On 9/28/07, David Jencks <da...@yahoo.com> 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.
>
Thanks David for clarifying this. We know any onlooker with incomplete
information could fall into the same
situation especially when we reject a contribution.
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.
>
<pmc-memeber-hat-on>
We unfortunately had a less than ideal situation here with code dumping in
the past. As a result we must now "manage"
a specific committer's activities. We trust all of our folks at the start
since we vote them in and see it as a chore to have
to manage anything at all. We, the PMC, feel very good vibes from people
like yourself who have the right intentions.
</pmc-memeber-hat-on>
I personally feel bad that I did not have the time to help when you needed
it with your patches: which all btw met our
criteria. I think we've rectified that and can continue forward.
Thanks,
Alex
Re: [Kerberos] PKINIT support
Posted by David Jencks <da...@yahoo.com>.
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
> 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.
>
> 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 <en...@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
>>
>
Re: [Kerberos] PKINIT support
Posted by Emmanuel Lecharny <el...@gmail.com>.
<chair hat on>
At this point, I suggest that we close this thread. It does not bring
a lot of valuable goods to the project and the community.
I would like to add that I don't think bridges has been burned. David
expressed some valid concerns, and he may have not be aware about what
has happened 8 months ago, so this is fair to consider that he sent
his mail on good faith.
What is important is not necessarily what happened 8 months ago, but
how we try to avoid such situations to ever happen again. This is the
PMC duty to work hard on that.
<chair hat off>
Peace,
Emmanuel, aka Cameron ;)
On 9/23/07, Alex Karasulu <ak...@apache.org> wrote:
> We've had issues with Enrique code dumping here. You're totally unaware of
> things that have happened in
> the past which are covered on our private list. So you're now talking
> without a priori knowledge.
>
> New features are great things. As I said I would love all the ideas Enrique
> has had to be incorporated into
> the server. But dumping code is not acceptable. Notice we are not closed to
> others adding new features
> because we trust that they will support it.
>
> When the same person who does not support virtually every features they have
> added then we have an issue.
>
> You might want to ping me the next time you write such a nasty email
> attacking my character or to post
> something to private at before getting all righteous. Then you can
> understand what's going on.
>
> Alex
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [Kerberos] PKINIT support
Posted by Alex Karasulu <ak...@apache.org>.
We've had issues with Enrique code dumping here. You're totally unaware of
things that have happened in
the past which are covered on our private list. So you're now talking
without a priori knowledge.
New features are great things. As I said I would love all the ideas Enrique
has had to be incorporated into
the server. But dumping code is not acceptable. Notice we are not closed to
others adding new features
because we trust that they will support it.
When the same person who does not support virtually every features they have
added then we have an issue.
You might want to ping me the next time you write such a nasty email
attacking my character or to post
something to private at before getting all righteous. Then you can
understand what's going on.
Alex
Re: [Kerberos] PKINIT support
Posted by David Jencks <da...@yahoo.com>.
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
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.
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 <en...@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
>
Re: [Kerberos] PKINIT support
Posted by Alex Karasulu <ak...@apache.org>.
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 <en...@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
>