Re: 'gsasl' command-line utility bad for automated testing

[Simon Josefsson]

Jacek Konieczny <address@hidden> writes:

> Hello,
>
> As a part of my Python XMPP implementation 
> (https://github.com/Jajcus/pyxmpp/, 
> https://github.com/Jajcus/pyxmpp2/) I am writing a Python implementation
> of some basic SASL mechanism. I wanted to make some test scripts for
> that, to discover any regressions and to ease implementing new
> mechanism.
>
> I was happy to find out, that the GNU SASL library provides a
> command-line utility to interface that. Unfortunately, making it
> work in an automated test script was a nightmare.

Hello.  Thanks for your interest and feedback!

I can imagine that you would have these problems with it, the gsasl tool
was designed and intended for interactive debug purposes.  How about
adding a --batch parameter for automated situations like yours?

> Some of the problems:
> - input expected by the script or the output it is supposed to generate
>   is not documented anywhere, except the console messages displayed when
>   not run '--quiet'.

The --batch mode could be well defined and documented.

> - apart from the SASL challenge/response messages the utility
>   occasionally (sometimes before the first message, sometimes in the
>   middle of conversation) asks for other parameters on stdin. Even to
>   get a full list of supported client mechanism I need to send something
>   (channel binding data) to the gsasl's stdin.

Yes, this is awkward but reflects how the mechanisms query for some
parameters.  Some mechanisms are not available if channel bindings are
not available.

Hm.  Maybe there should be a --channel-binding parameter to let the
caller specify the CB data manually.  For debugging purposes.

> - as any new gsasl version may ask for some new or different parameters
>   I can expect my script work only with one gsasl version I tested it
>   with. The new parameters will cause problems even if they are
>   'optional' (pressing 'Enter' to ignore them when using interactively
>   would be enough). It would be better if the tool doesn't ask for
>   anything when used non-interactively and fail only if some critical
>   data is missing on the command line.

Sounds like something for --batch.

> - data sent to stdin is echoed back to stdout, with some control
>   characters (line editing?). One has to filter that out to get the
>   actual SASL response

Anything other than a \n (newline)?  Maybe a \r in there?  If so, that
would be a bug.

> - stdout is also used for some diagnostic messages ("Mechanism
>   requestes...") which also need to be filtered out. Those should rather
>   be sent to stderr.

I agree, fixed on master.

> - There is no clear way to say when the authentication is finished, as
>   the utility doesn't exits, but starts to read 'application data' from 
>   stding. This seems to be a configuration option, but one that can only
>   be enabled and which is enabled by default:
>
>>  -d, --application-data        After authentication, read data from stdin 
>> and 
>>                                  run it through the mechanism's security 
>> layer 
>>                                  and print it base64 encoded to stdout. The 
>>                                  default is to terminate after 
>> authentication. 
>>                                   (default=on)

You can specify -d to toggle it off.

> I hope the utility can be improved to satisfy the automated use case.
> Especially it seems it was thought for such purpose too.

Not really, but I can see how it would be useful.  Maybe we could work
out how a --batch mode would work?  Something like this maybe:

SERVER-LIST: CRAM-MD5 SCRAM-SHA-1  <- gsasl writes
CLIENT-START CRAM-MD5  <- your application writes
SERVER-CHALLENGE: b64-data <- gsasl writes
CLIENT-RESPONSE: b64-data <- your application
...
SERVER-STATUS: OK/NO ("error-code")

It would never write anything else except label-prefixed data like
SERVER-LIST, SERVER-CHALLENGE, SERVER-STATUS etc.  It would never query
for anything else, all data has to come from command line parameters.

The gsasl command line tool is written in a fairly ugly code style
compared to the rest, maybe this could be a good reason to rework it...

/Simon