Re: krb5dissect

[Simon Josefsson]

Russ Allbery <address@hidden> writes:

>>> 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.)

As far as I can tell, 'klist' cannot output:

* raw encryption keys for ccache
* raw krb5 tickets

And generally its output is highly parsed and formatted compared to
krb5dissect which just output the raw contents of the file.

This discussion has made me realize that perhaps there is some other
potential for krb5dissect, to convert ccache/keytab into a text format
that can be transported, or possibly into/from a standard-format for
transferring credentials (possibly IETF's keyprov, although they seem
to use rather complicated XML to do this).  But I'm not sure it will
be anything more than a debug tool to parse ccache/keytab's directly.

Also, since the ccache/keytab format isn't a standard, it may be
useful to have a decoder written the way I interpreted the format, and
have 'klist' do whatever MIT thinks it should do.  MIT may enhance the
format, and then being able to debug why Shishi doesn't handle new
formats properly may be useful.

>> 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.

That's what I thought too.

>> 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.

That's very good.  Is there any chance your pam_krb5 could become
modular enough so that the krb5-specific calls are isolated and could
be replaced?  Or do you think it is not worth the effort?  I don't
have resources to work on pam_shishi/krb5 but perhaps a GSOC project
is accepted to modularize pam_krb5 and add Shishi support.

/Simon