[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mon, 29 May 2006 12:25:18 +0200
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)))
I would have probably used something with continue, but
> > - 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
> 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
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...)