Re: SASL success responses

[Glenn Maynard]

On Mon, Jun 6, 2011 at 4:03 PM, Simon Josefsson <address@hidden> wrote:

Hi Glenn!  Thanks for your interest and pondering here.  I agree with
you, and I changed the logic for 1.5.0 and later and it does return
GSASL_OK in step 1.  Which version are you looking at?

However I never resolved in a good way your followup-question.  I think
your idea to separate OK-without-data from OK-with-empty-data by using
NULL vs "" is a good idea.

1.4.4, the version shipping in current Debian.  They do tend to lag behind a bit.

(FYI, I'm no longer concerned with my original problem--that project is dead and I've switched codebases.)

I am worried what effect this would have on existing applications,
though, if they now start to receive NULL on GSASL_OK.  And whether we
would have to bump the ABI version due to this.  But I never did for the
GSASL_OK/GSASL_NEEDS_MORE change, so I guess we could do this.

 

I'm sure applications would break, not expecting a null response.  I'd be wary, since SASL is by nature security-sensitive.

You could allocate a sentinel, eg:

    static const char *const GSASL_FINISHED = strdup("");

    ret = gsasl_step(&ctx, in, len, &out, &outlen);
    if(ret == GSASL_OK && out == GSASL_FINISHED) ...

which would give the same API for applications not expecting it--an empty string--but the specific condition can be detected by address.  It's generally unidiomatic, though.

Alternatively, create a context flag, eg. gsasl_enable_null_responses(&ctx) to enable the new behavior for a version or so, emitting warnings if it's not set and eventually making it the default.  It depends on the level of binary compatibility you want to maintain, of course.

-- 
Glenn Maynard