help-gsasl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

'gsasl' command-line utility bad for automated testing


From: Jacek Konieczny
Subject: 'gsasl' command-line utility bad for automated testing
Date: Fri, 27 May 2011 21:35:21 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

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.

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'.
- 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.
- 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.
- 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
- stdout is also used for some diagnostic messages ("Mechanism
  requestes...") which also need to be filtered out. Those should rather
  be sent to stderr.
- 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)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]