search

dlgroep / fetch-crl

The fetch-crl utility will retrieve certificate revocation lists (CRLs) for a set of installed trust anchors, based on crl_url files or IGTF-style info files. It will install these for use with OpenSSL, NSS or third-party tools.
https://www.nikhef.nl/pdp/fetchcrl3/
Apache License 2.0
6 stars 0 forks source link

Support https_proxy #1

Closed dhoffend closed 1 year ago

dhoffend commented 1 year ago

The current implimentation doesn't support or honor a https_proxy configuration or environment variable. Since LWP::Useragents needs to have the https proxy configured separately downloads from https websites are not working at all when only http_proxy is set.

Please support https_proxy. If needed I can write a pull request

dlgroep commented 1 year ago

Thanks for the report - to clarify the use case a bit further: would it be adequate to use the same proxy endpoint for both http and https, or are distinct endpoints required? The former would make the configuration of fetch-crl slightly simpler. Happy to implement this one!

dlgroep commented 1 year ago

As a short-term workaround, you can set in the /etc/fetch-crl.conf file (or in /etc/fetch-crl.d/):

http_proxy = ENV

and then set the environment variables http_proxy and https_proxy. LWP will then load proxy settings from the *_proxy environment variables.

dlgroep commented 1 year ago

Branch https://github.com/dlgroep/fetch-crl/tree/https-proxy-rc adds support for explicitly setting https_proxy, and makes the same (existing) http_proxy setting also apply to https transfers (https_proxy can then be used to override this). The setting is mutually exclusive with http_proxy=ENV for obvious reasons :) A preview build and assembled fetch-crl version (3.0.23-RC) is available from https://dl.igtf.net/distribution/tests/PMA-PRIVATE-PREVIEW/fetch-crl3/

dhoffend commented 1 year ago

As a short-term workaround, you can set in the /etc/fetch-crl.conf file (or in /etc/fetch-crl.d/):

http_proxy = ENV

and then set the environment variables http_proxy and https_proxy. LWP will then load proxy settings from the *_proxy environment variables.

In my use case, the webpage I had to download the revocation lists from a server that was https only. I did a similar workaround (setting http_proxy and https_proxy at once). Technically correct would be to configure both seperate (like it must be done in ENV), but for 99% of the use cases, setting both at the same time should be okay. It should be mentioned in the documentation/changelog that both will be set or both can be configures seperate.

dhoffend commented 1 year ago

I'm okay with your solution. For more complex configurations the usage of ENV is more suitable. In the beginning I didn't realized the possibilty.

dlgroep commented 1 year ago

Thanks for the feed-back. In 3.0.23, the default is now to configure both, but the https_proxy can then additionally be set explicitly (and thereby making it different from http_proxy). If this branch meets the use case, I'll consolidate and release a new version. In due course, this will end up in oft-used (Linux) package repositories as well (Debian and Fedora EPEL).