This has been a side project of mine for a little bit.
https://github.com/mikem23/koji-playground/tree/use-requests-2
It started out as part of the work on porting to py3, but with all the pain we've had with the old ssl code path, it seemed desirable to deal with this separately.
This isn't quite ready for a PR yet, but the code is working for me, even on RHEL-5 (though I definitely need to test more there). I could really use some feedback.
To deal with backwards compatibility, I wrote a very basic "requests-like" shim that handles requests via the old code. The client uses requests by default if it is available and falls back to the shim if not. You can force the fallback with the use_old_ssl option.
One of the challenges of using requests is that it (correctly) stricter about certificates. At the moment, I'm suppressing warnings from urllib3. It warns (loudly) if verify is turned off (currently only possible via the no_ssl_verify session option). It also warns if the server ca lacks subjectAltName.
At the moment, the new codepath verifies by default, which is new behavior. The serverca option is now passed into the session at creation, not just during ssl login. Some folks may find that connections fail with a cert error. They should either ensure that serverca is set, or that their ca is trusted by their system.
Since this is a client change, it is easy to test out directly from a git clone. Many of you probably know how to do this, but just in case....
$ git clone https://github.com/mikem23/koji-playground.git -b use-requests-2 $ cd koji-playground/ $ PYTHONPATH=. cli/koji hello
(just use the -p option if you need to use a different profile. e.g. brew, cbs, koji-ppc)
Dne 7.10.2016 v 16:46 Mike McLean napsal(a):
This has been a side project of mine for a little bit.
https://github.com/mikem23/koji-playground/tree/use-requests-2
It started out as part of the work on porting to py3, but with all the pain we've had with the old ssl code path, it seemed desirable to deal with this separately.
This isn't quite ready for a PR yet, but the code is working for me, even on RHEL-5 (though I definitely need to test more there). I could really use some feedback.
To deal with backwards compatibility, I wrote a very basic "requests-like" shim that handles requests via the old code. The client uses requests by default if it is available and falls back to the shim if not. You can force the fallback with the use_old_ssl option.
One of the challenges of using requests is that it (correctly) stricter about certificates. At the moment, I'm suppressing warnings from urllib3. It warns (loudly) if verify is turned off (currently only possible via the no_ssl_verify session option). It also warns if the server ca lacks subjectAltName.
At the moment, the new codepath verifies by default, which is new behavior. The serverca option is now passed into the session at creation, not just during ssl login. Some folks may find that connections fail with a cert error. They should either ensure that serverca is set, or that their ca is trusted by their system.
Since this is a client change, it is easy to test out directly from a git clone. Many of you probably know how to do this, but just in case....
$ git clone https://github.com/mikem23/koji-playground.git -b use-requests-2 $ cd koji-playground/ $ PYTHONPATH=. cli/koji hello
(just use the -p option if you need to use a different profile. e.g. brew, cbs, koji-ppc) _______________________________________________ koji-devel mailing list -- koji-devel@lists.fedorahosted.org To unsubscribe send an email to koji-devel-leave@lists.fedorahosted.org
I've played a little with it and more general question: Don't we want to fail on any SSL error now? Now reraising exception is based only on is_cert_error validator, but probably most SSL errors are not recoverable (my typical case is fedora ssllogin page and SSL_HANDSHAKE_FAILURE). So, maybe enumeration of exceptions we believe are terminal or just fail on any SSL error? Either of these is different to previous behaviour (some SSL errors were silently masked).
I've played a little with it and more general question: Don't we want to fail on any SSL error now? Now reraising exception is based only on is_cert_error validator, but probably most SSL errors are not recoverable (my typical case is fedora ssllogin page and SSL_HANDSHAKE_FAILURE). So, maybe enumeration of exceptions we believe are terminal or just fail on any SSL error? Either of these is different to previous behaviour (some SSL errors were silently masked).
This work is more of a direct port of the existing code, so this is a separate question.
That said, ... maybe... the question is, is it possible for some strange network behavior or transient httpd misbehavior to result in an SSL exception.
Also, I think perhaps we may want should be different retry behavior in different circumstances. E.g. the first call, vs later calls, vs the sslLogin call.
On 10/07/2016 10:46 AM, Mike McLean wrote:
This has been a side project of mine for a little bit.
https://github.com/mikem23/koji-playground/tree/use-requests-2
So far I've heard no negative feedback. I've added a couple minor fixes and some unit tests since starting this thread.
I filed this as a PR today. Please review if you have time https://pagure.io/koji/pull-request/213
It started out as part of the work on porting to py3, but with all the pain we've had with the old ssl code path, it seemed desirable to deal with this separately.
This isn't quite ready for a PR yet, but the code is working for me, even on RHEL-5 (though I definitely need to test more there). I could really use some feedback.
To deal with backwards compatibility, I wrote a very basic "requests-like" shim that handles requests via the old code. The client uses requests by default if it is available and falls back to the shim if not. You can force the fallback with the use_old_ssl option.
One of the challenges of using requests is that it (correctly) stricter about certificates. At the moment, I'm suppressing warnings from urllib3. It warns (loudly) if verify is turned off (currently only possible via the no_ssl_verify session option). It also warns if the server ca lacks subjectAltName.
At the moment, the new codepath verifies by default, which is new behavior. The serverca option is now passed into the session at creation, not just during ssl login. Some folks may find that connections fail with a cert error. They should either ensure that serverca is set, or that their ca is trusted by their system.
Since this is a client change, it is easy to test out directly from a git clone. Many of you probably know how to do this, but just in case....
$ git clone https://github.com/mikem23/koji-playground.git -b use-requests-2 $ cd koji-playground/ $ PYTHONPATH=. cli/koji hello
(just use the -p option if you need to use a different profile. e.g. brew, cbs, koji-ppc) _______________________________________________ koji-devel mailing list -- koji-devel@lists.fedorahosted.org To unsubscribe send an email to koji-devel-leave@lists.fedorahosted.org
koji-devel@lists.fedorahosted.org