-
Notifications
You must be signed in to change notification settings - Fork 328
Switch to GH-Actions #634
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
Switch to GH-Actions #634
Conversation
Tests are failing due to SSL errors, which are caused by invalid config and/or incorrectly generated certificates. As we do some hackety hackery to mimic different ssl weirdiness, it might be the problem of misconfiguration, but I can't figure out what exactly isn't correct. |
I tend to disable failing specs temporarily and address those as a separate pr (help is super welcomed). @tarcieri wdyt? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's an open issue for the SSL-related failures: #627. I'm also not sure what's up there... I'm guessing something changed related to either accepted algorithms or hostnames.
Otherwise, this looks good!
* Use GitHub Actions for CI * Update Coveralls integration: generate lcov report with SimpleCov and send it after the test suite using coveralls GitHub Actions plugin * Update and cleanup RSpec config * Cleanup Rakefile * Remove active_model dependency (certificate_authority was fixed) PS: GH Actions syntax is ugly. Should we switch to Cirlce CI or GitLab CI? XD Resolves: #633
446845d
to
ddaddd2
Compare
Specs are failing due to some misconfiguration caused by new OpenSSL. TODO: #627
ddaddd2
to
2ae6a71
Compare
We were not testing those on Travis-CI, thus to simplify migration I've deicded to disable those. Once everything is fixed and stabilized we will add those too.
Just to make sure we're using expected ones
- use stub_const - consistently normalize URIs
/cc @tarcieri Probably we should just add dependency on gem itself?
This reverts commit f8dfb38.
jRuby is using outdated openssl gem bundled in, which don't have validate_hostname getter on SSLContext.
@@ -36,8 +36,9 @@ def start_tls(host, ssl_socket_class, ssl_context) | |||
connect_ssl | |||
|
|||
return unless ssl_context.verify_mode == OpenSSL::SSL::VERIFY_PEER | |||
return unless ssl_context.respond_to?(:verify_hostname) && ssl_context.verify_hostname |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In hindsight, this should probably have been:
return if ssl_context.respond_to?(:verify_hostname) && !ssl_context.verify_hostname
...so as to only support explicitly disabling hostname verification. As is, it seems hostname verification won't be performed on JRuby at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened #636 as a follow-up to this comment.
Following up on this comment: #634 (review) The previous logic skipped hostname verification entirely if the `verify_hostname` method is not defined for `OpenSSL::SSL::SSLContext`, which is currently the case for JRuby. This commit changes the logic so if that method is undefined, hostname verification is still performed. Otherwise, hostname verification would always be skipped on Rubies which don't define a `verify_hostname` method. Note that this was *just* introduced in #634 which was merged 10 hours ago, so I think this was caught quickly enough simply correcting it suffices and there isn't additional security-related followup here (e.g. CVE)
Following up on this comment: #634 (review) The previous logic skipped hostname verification entirely if the `verify_hostname` method is not defined for `OpenSSL::SSL::SSLContext`, which is currently the case for JRuby. This commit changes the logic so if that method is undefined, hostname verification is still performed. Otherwise, hostname verification would always be skipped on Rubies which don't define a `verify_hostname` method. Note that this was *just* introduced in #634 which was merged 10 hours ago, so I think this was caught quickly enough simply correcting it suffices and there isn't additional security-related followup here (e.g. CVE)
Thanks for the fix |
Resolves: #633