Re: Server querying of mechanism needed properties

[Phil Pennock]

On 2012-02-20 at 12:13 +0100, Simon Josefsson wrote:
> Phil Pennock <address@hidden> writes:
> > I've implemented GSASL as an authentication driver for Exim; currently
> > server-only and experimental.
> 
> Hi Phil and welcome to the list!  First apologies for slow response, I
> wanted to get 1.7.1 out before responding to your e-mail, however after
> making the release my spare time went away.
> 
> Thanks for working on Exim patches, I'll be happy to help with that and
> ultimately to test them (I use exim as the MTA on several machines).  Is
> the gsasl patches discussed on some exim mailing list?
> 
> > Exim is an MTA (Mail Transfer Agent) with a history of supporting
> > multiple implementations of functionality, eg OpenSSL + GnuTLS.  In this
> > case, there are some simple native drivers, Cyrus SASL and now GSASL.
> >
> > The code changes to Exim, for the curious, can be found at:
> >   https://github.com/Exim/exim/compare/master...gsasl
> 
> This link doesn't work for me.

Oops!  I should not have deleted the branch on github after integrating
it to master.  Sorry.

The core of the code is in gsasl_exim.[ch] found at:
  http://git.exim.org/exim.git/tree/master:/src/src/auths
  https://github.com/Exim/exim/tree/master/src/src/auths

> Fixed in master now.  I've been thinking of renaming GSASL_AUTHID to
> GSASL_USERNAME for some time now, and maybe now is a good time.  The
> risk of confusing these two symbols is non-negligible, and USERNAME is a
> better word than AUTHID even though it is not as RFC4422-like.

As long as GSASL_AUTHID remains defined, I'm happy; note that
GSASL_NO_AUTHID would also need to become a compatibility name, for
consistency.

The issue here is that the pre-processor doesn't know which enum names
exist, so there's no sane way to check which version is being built
against.  When a system is acting as a dedicated mail-server, then the
MTA is a piece of software which the postmasters may often choose to
maintain locally, instead of relying purely upon package management, so
Exim gets built from current source against some rather old releases.

It doesn't look as though gcc has an extension to mark an enum symbolic
name as deprecated, only variables, functions and types.

> Good idea, I hadn't thought of that, but it makes sense.

*phew*  Suddenly I feel a lot happier about having committed my fellow
maintainers to ongoing support of a second SASL library API.  :)

> >      Alternatively, given that different callback properties can be
> >      used, with fallbacks, perhaps a way to query "will this set of
> >      properties be sufficient for this mechanism; if not what is
> >      missing?"
> 
> Yeah, although that is more complex.  But maybe we need to express that
> property X, Y Z are _required_ and either property A or B is _required_,
> and property G, H and I are _optional_.  There could even be situations
> where property P and Q are both optional, but if P is specified so must
> Q be.

The key of the proposal is not to ask what is required, but to ask
"given what I'm already offering you, what am I going to need to prompt
for"; perhaps a vector of sets of results, which are not guaranteed
unique?

> There is gsasl_property_fast, does it do what you want?  It will return
> NULL if the property doesn't have any value, rather than invoking the
> callback.

I think so.  I ended up switching to this.  For some reason, I had
thought this was an internal method and it didn't sink in, first time
around, that this was external API with guaranteed semantics.

> I agree.  However, I believe "realm" is optional in the protocol
> though.  Compare RFC 2831:

Hrm.  Sorry about that.  I will go fix the diagnostic tool I was using
for testing.

Thanks,
-Phil