Kerberos and OpenSSH - Was:Kerberos password auth/expiry kbdint patch

Damien Miller djm at
Fri May 16 10:14:01 EST 2003

Frank Cusack wrote:
> On Thu, May 15, 2003 at 10:06:10AM +1000, Damien Miller wrote:
>>  a) kerberos-2 at can coexist with Simon's code, should it be
>>     merged at some future time;
>>  b) Simon's code consititutes two orders of magnitude more change
>>     than what Markus committed;
> Yet you just committed a large PAM change, probably broken (by your
> own statement when you announced the commit).  I'd say the PAM change
> is more severe than the GSSAPI change (maybe not in sheer LOC, but
> certainly in scope).

Rubbish, there is no comparison.

For a start, the changes are shorter[1] (in LoC and scope) and remove as
much code as they add. More importantly, I have been examining and
merging the code (on and off) for six months. Finally, it changes code
that was largely written by me in the first place, so I am familiar with it.

I am yet to hear reports of breakage in the new PAM code, BTW.

> You will probably want to argue that FreeBSD's been using it for some
> time, but FreeBSD isn't really the reference PAM platform ...

What is? Sun? Linux?

As far as I am concerned they are all broken. OpenPAM certainly seems to
be the least broken implementation, having had the opportunity to learn
from the mistakes of others. (Though I think the brokenness starts with
the standard and not any one implementation.)

>>  c) not all the developers are familiar with Kerberos and GSSAPI;
> Of course not.  Different developers work on different parts of the code.
> Get some developers that ARE familiar with krb5 and GSSAPI.  To name two,
> Nicolas Williams and Simon Wilkinson are certainly pretty capable.

As Ben mentioned, they are not the ones who are called to account when
things go bad.

(please don't infer any criticism of Simon's code from my/our paranoia)

>>  d) Simon's code is still going through the IETF process, whereas
>>     SSH.COM's is very minimal (basically a cleanup of the protocol 1
>>     Kerberos support) and therefore less likely to change;
> ssh itself is still going through IETF.  It's well known that kerberos-2
> is broken; SSH.COM's code isn't even IN the IETF!  Even if GSSAPI changes,
> it's not like you don't already have bunches of compability hacks in the
> code.  SSH.COM's code, being proprietary, and having known broken bits,
> is more likely to change IMHO.

Repeating myself (yet again): the new protocol 2 Krb auth method is a
near copy of what we have been using for protocol 1 for years.


[1] 17 files changed, 828 insertions(+), 563 deletions(-)

More information about the openssh-unix-dev mailing list