Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not treat errors as success #66

Merged
merged 2 commits into from
Sep 18, 2014
Merged

Do not treat errors as success #66

merged 2 commits into from
Sep 18, 2014

Conversation

macintux
Copy link
Contributor

As discussed in #65 (at least two problems tackled there, so this does not yet suffice to close the ticket) the function sent to the OTP SSL libraries for supplemental certificate validation should fail by default, not succeed.

I have not been able to generate certificates that demonstrate the undesirable behavior for automated testing, but certificates originally created by @bkerley revealed the problem and were used to test this fix.

validate_function(_,{bad_cert, _} = Reason, _) ->
{fail, Reason};
validate_function(_,{extension, _}, UserState) ->
{unknown, UserState}.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless we have a style guide that says to omit them, I'd rather have a _Cert variable than _.

Also, should we still have a catch-all function that returns valid/fail/unknown/something?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point about the anonymous bindings, will tweak that.

The public_key OTP library handles the real smarts here; our function just allows us to do some extra checks. By passing back what came in if we don't need to do anything, we're letting it make the real decisions. So if a failure or unknown status comes in, we'll let it decide what to do. It's the same as if we didn't supply the function at all.

See pubkey_cert:verify_fun if you'd like more context.

@hazen
Copy link

hazen commented Sep 18, 2014

Huzzah! I have been able to now see this error in the Python client:

SecurityError: [('SSL routines', 'SSL3_READ_BYTES', 'tlsv1 alert unknown ca')]

@macintux
Copy link
Contributor Author

@bkerley Back to you. I'm satisfied that @javajolt has tested and verified the same behavior I've seen and expected.

@macintux
Copy link
Contributor Author

@bkerley has successfully tested the new branch with new certificates, using c-ruby. The only other test I'd like to see is verification that the old buggy certificates are not authenticated successfully using this branch. @javajolt has, however, already tested that using Python, so at this point, Bryce, even that test is optional.

I think this is good, but leaving is to Bryce to make the call.

@bkerley
Copy link

bkerley commented Sep 18, 2014

+1 4d10c83

I'm satisfied with how it works against the Ruby client.

borshop added a commit that referenced this pull request Sep 18, 2014
Do not treat errors as success

Reviewed-by: bkerley
@macintux
Copy link
Contributor Author

@borshop merge

@borshop borshop merged commit 4d10c83 into 2.0 Sep 18, 2014
@seancribbs seancribbs deleted the jrd/issue/65part2 branch January 7, 2015 17:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants