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
$ 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(a)lists.fedorahosted.org
To unsubscribe send an email to koji-devel-leave(a)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
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
Tomas Kopecek <tkopecek(a)redhat.com>
Release Engineering Development, RedHat