Hi daniel

>My only concern with the added ifdefs for the memory handling is that the
source code seems to imply that it can work with both gssapi and spnego
present at the same time and then it isn't correct to select the method at
compile-time but it should instead be decided in run-time.

>Do you agree?

Yes daniel I agree. Actually fbopenssl's job is to convert negotiate tokens
from one format to another(typically gssapi standard to spnego). They cater
to different rfcs. SPNEGO is the one used in all http communication. For
example my server is a tomcat implementation which only accepts SPNEGO
tokens. So in the event the code is compiled with HAVE_SPNEGO as a
preprocessor directive, the SPNEGO operation builds on top of the gssapi
one. In other words, if both are together, only SPNEGO token goes to server.
Now

neg_ctx->output_token.value = spnegoToken.value;
neg_ctx->output_token.length = spnegoToken.length;

happens in spnego compiled code in case fbopenssl succeeds in the
conversion. Thus the variable contains spnego token which was allocated
using standard malloc(). If not compiled, it contains standard gssapi token
not allocated by malloc. Hence the patch is also designed the same way. In
spnego is done, the spnego token (neg_ctx->output_token.value) is always
malloced and hence must be freed equivalently.

I hope this dispels your concerns

Yours sincerely

-- 
Arunav Sanyal
Graduate student
B.E (Hons) Computer Science
BITS Pilani K.K Birla Goa Campus
Software Engineer
INFORMATICA BUSINESS SOLUTIONS

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-09-18