On Mon, Feb 24, 2003 at 08:01:39PM +1100, Luke Howard wrote:
>
> >You may want to omit the USE_KEYTAB patch to passdb/secrets.c: we don't
> >actually use that, and without support for updating the secret, it may
> >be of limited use.
>
> Actually, there are a couple of memory leaks in secrets_fe
>You may want to omit the USE_KEYTAB patch to passdb/secrets.c: we don't
>actually use that, and without support for updating the secret, it may
>be of limited use.
Actually, there are a couple of memory leaks in secrets_fetch_keytab_password(),
too so if you intend to include it -- let me send
Here's a revised patch that cleans up a few of the issues you mentioned.
You may want to omit the USE_KEYTAB patch to passdb/secrets.c: we don't
actually use that, and without support for updating the secret, it may
be of limited use.
-- Luke
Index: configure.in
===
On Mon, 24 Feb 2003, Luke Howard wrote:
>
> Hi Andrew,
>
> >Doesn't the kerberos deal with the byte order? Or shouldn't we create a
> >asn1_write function to do this?
>
> The token ID is not ASN.1. Read RFC 1964.
Wow, I recall saying this twice before :-(
> >Can we have a name for this magi
Hi Andrew,
>Given the non-invasive nature of this patch, I'll add it without the
>#ifdef. Would it be possible for you to add 'write' support to this?
>(Changing the password and storing it into that keytab).
Shouldn't be too hard: note, though, we don't store the cleartext password
in the key
On Sun, 2003-02-23 at 13:06, Luke Howard wrote:
>
> The attach patch contains the following enhancements to HEAD:
>
> 1. Support for using Kerberos keytabs (configure with --enable-keytab)
>instead of the secrets database, for the local machine password.
Given the non-invasive nature of this
The attach patch contains the following enhancements to HEAD:
1. Support for using Kerberos keytabs (configure with --enable-keytab)
instead of the secrets database, for the local machine password.
2. Mutual Kerberos GSS-API SPNEGO authentication.
3. Support for extracting the SMB session ke
