:thumbsup:

Any compatibility concerns? Have we tested this on RHEL6?

In the unit test, it looks like we are explicitly passing the default value of no_ssl_verify=False.
Is this necessary here? Should we add a test where we set the value to True?

Works for me on RHEL6 (python-pycurl-7.19.0-9.el6).

While it mostly does make sense to have downloads honor this setting, I'm afraid that we'll be encouraging many more folks to turn that option on than should.

Koji configurations should use the serverca setting for hosts with certs that are not trusted at the system level. The no_ssl_verify option should only be used as a last resort, and preferably only temporarily. It is, of course, unsafe.

This change provides no way to indicate a trusted ca for the download server, and I'm not quite sure how that should work. I suppose we could also honor serverca, but is probably not correct for many setups.

Consider my local test instance with ssl auth. I am not using no_ssl_verify and koji works fine.

$ lkoji hello
안녕하세요, mikem!
You are using the hub at https://localhost/kojihub
Authenticated via client certificate /home/mike/.koji/mikem-local.crt

However, as this issue points out, the download code fails:

$ lkoji download-build zip-3.0-15.fc23
Downloading: zip-3.0-15.fc23.i686.rpm
Traceback (most recent call last):   ]  00%     0.00 B
  File "/home/mike/Devel/koji/koji/cli2/lkoji", line 310, in <module>
    rv = locals()[command].__call__(options, session, args)
  File "/home/mike/Devel/koji/koji/cli/koji_cli/commands.py", line 6600, in anon_handle_download_build
    no_ssl_verify=options.no_ssl_verify)
  File "/home/mike/Devel/koji/koji/cli/koji_cli/lib.py", line 502, in download_file
    c.perform()
pycurl.error: (60, "Peer's certificate issuer has been marked as not trusted by the user.")

I should not have to expose my rpc calls to a man-in-the-middle attack in order to fix the download issue.

A better workaround for folks with this issue might be to use http: rather than https: for their topurl setting.

The could also trust the cert at the system level (granted most folks don't know how to do that).

Of course, we should fix this, and honoring no_ssl_verify here isn't strictly wrong, but I hate to make this the go-to workaround.

Some work here:
https://github.com/mikem23/koji-playground/commits/no_ssl_verify

Seems to work for me, but needs more testing.

I think this has convinced me that we should phase out our use of pycurl.

Yeah, I was thinking the same overnight. There should be probably some requests-based approach, so we can get rid of pycurl at all.

I've tried current code for fedora's instance and it works correctly (no problem with certs), so I would drop this PR and replace pycurl (with requests?) in 1.15.

Sounds good. We were already using pycurl for download-build in 1.13, so the current behavior should not be new. Not worth breaking the freeze for.

Also relevant: #294

Sounds good. We were already using pycurl for download-build in 1.13, so the current behavior should not be new. Not worth breaking the freeze for.

Just confirmed that I can replicate the behavior with 1.13.0 release

I've filed #PR 601 for removing pycurl.

PR #601 was merged, so I'm dropping this one.