Patches for UMich Replication

Kevin Coffman kwc at
Fri Oct 11 09:02:01 EDT 2002

> From: "Kevin Coffman" <kwc at>
> > I'll update the web page to show me as the contact.
> Thank you.
> > Could you elaborate on kinds of problems you were having?
> We have an application that runs on the KDC for a OTP system
> and it would core dump when changing passwords for users.
> > We have 
> > numerous principals with only a single key type and haven't run into 
> > this AFAIK.  Also, why is it only applicable when using the replication 
> > code?
> The application was crashing when being called from svr_principal.c:1214
> (that's the 1.2.5 version plus replication patches), inside a #if defined(UMICH),
> which I considered to be "replication code".
> My apologies if UMICH and UMICH_REPLICATION are separable,
> but I suppose it's a bug one way or another O:-)  Is there any reason for
> me to use one and not the other ?

The changes in UMICH_REPLICATION is the code to support our replication
scheme.  The changes in UMICH are various umich-specific changes.  I
believe the code you are referring to enforces password checking
regardless of whether a user has an associated policy or not.  This
is the same code that is executed in the non-umich code if the user
has an associated policy.  So, it seems that this would cause you
problems w/o the umich changes if the users have a policy.

I'd say your patch is relevant whether or not you are using the UMICH

> Are both of the alterations to MIT Kerberos as well tested as each other or has
> the UMICH_REPLICATION code been tested more then UMICH ?

We, of course, define both.  So both have the same amount of testing on
our end.  Perhaps you're exercising a code path that we don't normally
use.  Are you sure the segfaults are not a problem with the OTP

> > > Hi,
> > > I'm attaching some patches I found 'necessary' to stop applications
> > > crashing with the replication code from UMich because I can't find
> > > any contact email addresses on their web page or in the patch file.
> > > I initially sent of a pr to MIT for this but it's not really their problem.
> > > If others are using the UMich code, this patch may help them.
> > > The problem it attempts to address is when you've configured the
> > > KDC for more than one key type but the principals do not have
> > > key data for all key types.  If anyone else has come across this
> > > problem and has better/more/different patches to resolve this
> > > particular problem, I'd like to hear from them.
> Cheers,
> Darren

More information about the krbdev mailing list