Test suite: test passes

ghudson@MIT.EDU ghudson at MIT.EDU
Tue Mar 2 18:18:20 EST 2010

The dejagnu test suite is structured to run most tests a dozen or so
times with different settings, in order to exercise different parts of
the code.  The current passes are:

  * des             des as only supported_enctype
  * des.des3tgt     des as only supported_enctype; des3 krbtgt
  * des3            des3,des as supported enctypes
  * aes-des         aes256 and des as supported/permitted enctypes
  * aes-only        aes256 as supported/permitted enctype
  * aes-des3        aes256,des3,des as supported/permitted enctypes
  * aes-des3tgt     aes256,des3,des as supported/permitted etypes; des3 krbtgt
  * des-v4          des:v4 as supported_enctype; des as default_tkt_enctype
  * des-md5-v4      des-cbc-md5:v4 des-cbc-crc:v4 as supported_enctypes
                    des-cbc-md5 des-cbc-crc as client default_tkt_enctype
  * all-enctypes    default configuration
  * des.no-kdc-md5  KDC permits only des-cbc-crc
                    des-cbc-md5 des-cbc-md4 des-cbc-crc as default tkt/tgs

I'm trying to decide if these are the right passes for the
Python-based test infrastructure.  In particular:

  * The test suite support for changing the krbtgt to des3 dates back
    to 1999 when (I'm guessing) des3 support was just going in.  There
    are probably some interesting test scenarios where the krbtgt
    doesn't match the client's or KDC's most preferred enctype, but is
    there any need to treat des3 specially today?  If not, what are
    the best combinations to test without getting into combinatoric
    numbers of passes?

  * Are we spending too many passes on DES?

  * It doesn't look like we're exercising RC4 much.

Mainly, I'm hoping that people with more historical knowledge can help
identify specific areas of code which wouldn't get exercised with the
most obvious set of passes (like DES, DES3, RC4, AES as the only
supported/permitted enctypes).  Of course, it's possible that some of
those will be better handled through targeted tests (like "test if
kinit fails properly when default_tkt_enctypes doesn't overlap with
supported_enctypes") rather than the generic set of passes for "most"

More information about the krbdev mailing list