help-shishi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: krb5dissect


From: Russ Allbery
Subject: Re: krb5dissect
Date: Wed, 21 Mar 2007 13:01:14 -0700
User-agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)

Simon Josefsson <address@hidden> writes:
> Russ Allbery <address@hidden> writes:

>> Sure, I can sponsor this.  I have some other sponsorship requests I
>> need to look at first, but I should get to it within a week.

> Thanks!  If I'm going to rename the tool, you might want to hold off
> for a while...

Okay, I'll put it on the back burner for a bit.

>> I'm not entirely sure that I understand the utility, namely why I would
>> ever use this instead of klist, but I guess I see it well enough to be
>> willing to upload it.

> Krb5dissect is meant as a debug tool, similar to 'dumpasn1' or 'od'.
> 'klist' doesn't print all the details in the files.

Is this difference primarily when the file is corrupted?  (Basically what
I'm getting at is that if there's anything in a non-corrupted file that
klist isn't already showing, klist should probably be enhanced to do so.
Although that doesn't give you information like what format the ticket
cache is in, which may indeed be useful, which is why I talked myself into
uploading it.)

> Perhaps it isn't worth packaging, I guess I got carried away when
> creating a new project for this small thing.  Creating the Debian
> package for it was too simple, I guess.

*heh*.  It is very addictive.  Well, I don't think uploading it with
priority extra is really that big of a problem.  Having another package in
the archive shouldn't really hurt anything.

> Still, I know I will find it useful for debugging when I make Shishi use
> ccache/keytab's more, which is something I have decided to do.  It will
> make Shishi work more as a drop-in and avoid users from having to get
> the same credentials twice, once for MIT/Heimdal and once for Shishi.  I
> have to sort out how to work around the limitations of the formats.

Incidentally, while I know that Shishi has a different API and therefore
there is a good reason for it to have its own PAM module, I'd ideally like
to avoid too much duplication of effort around the PAM module design for
Kerberos.  That's one of the things I tried to fight with my pam-krb5;
right now, there are various forks and Sourceforge projects and none of
them give you everything that you want.  I'm trying to get everything into
one module, with all the options that people want, to try to cut down on
the confusion.

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]