[1182] in Kerberos_V5_Development
Re: key data version as array index
daemon@ATHENA.MIT.EDU (Christopher Provenzano)
Wed May 15 16:00:26 1996
Reply-To: proven@cygnus.com
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
In-Reply-To: Your message of "Tue, 14 May 1996 17:00:59 EDT."
<9605142100.AA09252@beeblebrox.MIT.EDU>
Date: Wed, 15 May 1996 15:57:24 -0400
From: Christopher Provenzano <proven@proven.org>
>
> I've seen code like this in a few places in libkdb:
>
> for (i = 0; i < key_data->key_data_ver; i++)
> if (key_data->key_data_contents[i])
> krb5_xfree(key_data->key_data_contents[i]);
>
> Basically, the code is using the key data version number as the
> maximum array index for the type, length, and contents field.
>
> As I've said, I'm currently documented libkdb which will include the
> definition of the various fields in the kdb structures. I've deduced
> from the code that in key_data_ver 1, the type, length, and contents
> arrays only had one element (key info), and that in version 2 they
> have two elements (key and salt info). Is that right? If so, the
> code above won't coredump, but still seems like a bad idea.
The idea is to keep things as compact as possible in the database. If
key_data_ver is 1 then the key is either a random key (not requiring a
salt) or the salt is the normal v5 salt which is the same as the realm
and therefore doesn't need to be saved in the database.
CAP
