[Top][All Lists]

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

Re: shishi_keys_for_serverrealm_in_file

From: Elrond
Subject: Re: shishi_keys_for_serverrealm_in_file
Date: Mon, 29 May 2006 12:25:18 +0200
User-agent: Mutt/1.5.9i

On Fri, May 26, 2006 at 10:45:43AM +0200, Simon Josefsson wrote:
> Hi!  Yes, it looks wrong.  I changed the logic to:
>       if ((!server ||
>          (shishi_key_principal (key) &&
>           strcmp (server, shishi_key_principal (key)) == 0)) &&
>         (!realm ||
>          (shishi_key_realm (key) &&
>           strcmp (realm, shishi_key_realm (key)) == 0)))
>       break;

I would have probably used something with continue, but
never mind.

> > - shishi seems to assume the whole way of hostkeys, that
> >   services have only one key?
> Yes, that seems wrong... I think there are two ways to solve this:
>  1) Have the functions take additional parameters, like etype, and
>     filter out hostkeys based on them, and only return one matching
>     key.
>  2) Have some meta-structure, a "key set", with all the keys for a
>     particular service, that can be passed to functions that require a
>     hostkey, and let the function decide which key to use (i.e., which
>     etype, which salt, etc...).
> The latter seem more generic, but also involve more work.  How are you
> using hostkeys now?  Maybe 1) would suffice.

I'm not using them at all.

I just looked at the inetutils patch in extras and followed
calls around in the source to see, what's happening here
and there.

So you're entirely free to choose what way you want to

> In general, the server-side (KDC/hostkeys) are the least tested part
> of shishi right now, so it isn't surprising that you run into these
> things.  I'll try to fix them though!

Right. my current target it client side support too.

(and w2k3 doesn't like my AP-in-GSSAPI-in-SPNEGO...)


reply via email to

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