Robert Relyea wrote:
> That being said, I suspect that we currently don't distinguish between
> these two, and wind up with a false success on expected client auth
> failure cases when the server is down. In practice that's not too much
> of a problem because several of the other tests in the suite will fail
> in that case.
> 
> Upshot: creating a rationalized error system from tstclnt sounds fine,
> as long that the tests are adjusted accordingly. (longer term, we may
> want to set the error code based on the PORT_GetError() value).

Bob, I think your suggestion makes a lot of sense. We can only return 255 
distinct error codes from tstclnt but there are many more possible error codes 
from PORT_GetError(). How about this updated proposal:

* Add an additional command-line flag "-E <error-id>" (e.g. "-E 
SSL_ERROR_CERT_DOMAIN") to tstclnt.
* If the flag is given and PR_Read() or PR_Write() fails with the given error, 
exit with code 2, which would mean "failed with the expected error".
* Otherwise, if error flag was given, and an error was encountered, exit with 
code 3, which would mean "failed with the wrong error."
* Otherwise, if the error flag was given, and no error was encountered, exit 
with code 4, which would mean "succeeded but expected to fail."
* Otherwise, return 1 on any error or 0 if there were no errors.

We could then make an analogous change to selfserv (hopefully in another bug).

Thoughts?

Cheers,
Brian
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to