Yes, I mean the program should exit with an error message if the requested CA file (either the default, or via -CAfile) can't be loaded.
On Fri, Apr 1, 2016 at 8:44 AM, Florian Zumbiehl <fl...@florz.de> wrote: > Hi, > >> Florian I'm happy to look at this now with you >> >> But based on the old discussion I'm not certain I'm happy with the >> final result. >> >> IMO - here's what we need in these: >> >> 1) If you specify nothing, you should get the default. >> 2) If you specify a CAfile, and there is no failure in loading it, >> you should get that. >> 3) If any failure occurs in either case 1 or case 2 the program >> should fail. Do not continue with something else. >> >> Try for the above > > Well, that's what the patch does? (With the slight modification that case 2 > also covers the CApath option, that is ...) > > Or do you mean that the whole program should abort instead of just warning > that the requested CAs couldn't be loaded and then just letting the > verification failure happen? > > While that in principle certainly would be sane default behaviour, I am not > sure whether it's a good idea in this case: At least s_server and s_client > are primarily debug tools and don't abort on authentication failure anyhow, > but just print a message, and also, I am not sure whether the default CAs > can always be expected to be available? > > The primary purpose of the patch is to make the output correctly reflect > the authentication status relative to what the user specified, so it > doesn't mislead the user when testing stuff, not to make it a secure TLS > client or server for production use. > > Regards, Florian
