[53] in GSSAPI Development
Re: Use of void *
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Wed Jun 5 14:25:35 1991
Date: Wed, 5 Jun 91 14:24:14 -0400
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: "John Wray, Secure Systems Development, DTN 226-6106 04-Jun-1991
Cc: gssapi-dev@ATHENA.MIT.EDU
In-Reply-To: John Wray, Secure Systems Development, DTN 226-6106 04-Jun-1991 0907's message of Tue, 4 Jun 91 06:23:10 PDT,
Reply-To: tytso@ATHENA.MIT.EDU
Date: Tue, 4 Jun 91 06:23:10 PDT
From: "John Wray, Secure Systems Development, DTN 226-6106 04-Jun-1991 0907" <wray@ultra.enet.dec.com>
>The C Bindings Spec should also specifically say that the programmer
>must assume that gss_pointer might be a void *, so that things like
>
> input_chan_bindings->acceptor_address.value[0] = ((to_addr & 0xff000000) >> 24);
> (from fcmd.c, approximately line 270)
>
>are explicitly disallowed. (Arithmetic using void pointers is extremely
>bad form.)
Where's the pointer arithmetic in the SPX code? Is to_addr a pointer?
The problem was with the acceptor_address.value[0]. Apparently SPX was
declaring the address as char * instead of a void *. No big deal; I
think making it be a gss_pointer type is the right way to go, though.
One other point. gss_init_sec_context and gss_accept_sec_context
return a flag saying whether confidentiality services will be
^^^^^^^^^^^^^^^
available from the context via the seal and unseal services. I'd
like to propose that we add an additional flag saying whether
per-message integrity services are available too. I'd propose
calling this flag GSS_C_INTEG_FLAG, and adding it to the ret_flags
parameter of both context establishment calls.
You mean "integrity services", right? That sounds fine to me.
- Ted
