Hi, > Basically - a root of trust is something sacrosanct. If you said "use > this root of trust" and somehow that fails, trying to run more code > when you *know* the requested root of trust did not work is very very > wrong. Do not proceed further, do not pass go, do not try to validate > the certificate anyway.. No good can come of this. > > And don't use the excuse they are debugging tools. if they are > debugging tools they should come closer to doing the right > thing.
Did you actually read what I wrote? I mean, I don't even really disagree with what you write, it's just that that's a separate issue from what the patch tries to fix. What's the point of aborting execution when a trust anchor doesn't exist if you lateron essentially ignore the authentication result anyway? It's a trust anchor without any trust anchored to it--except for the warning telling you that the verification failed, that is. Also, what about missing default CAs? Can that happen? Is that something that ought to work? Exactly because it is a debug tool, there absolutely is a case to be made for support of insecure use cases if that makes debugging easier. Making that the default probably still is a bad idea, but for one that's how s_client/server work for historical reasons, and, more importantly, it really is mostly a separate issue from what this patch is about. Now, if there are no bad side effects (like things failing to work when the default CAs are unavailable), it might well be a good idea to take the opportunity and also abort execution when loading any trust anchors fails, as that should be easy enough to change, I agree. Which is why I asked whether there are any such side effects, in case anyone knows. What do you think? Regards, Florian
