This has been a side project of mine for a little bit.
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)
This changes the arguments passed to the pre/postRPMSign callback. The
commit message and PR explain why I think it's necessary, and an
improvement. However, I wanted to gauge how disruptive this might be.
Have people written their own pre/postRPMSign callback handlers, that
will break because of this change?