-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
podman passes down http_proxy when it shouldnt #24838
Comments
|
should the default mimic docker for interchangeability? I'm not sure what the actual policy is for podman other than it seems to try to, most of the time. |
Well I don't know, except that if we change the default it would be a breaking change. We could change it in Podman 6.0 |
You can modify the containers.conf to set this setting to false.
|
my humble opinion would be it would make sense in this scenario, one less thing for people in a corporate environment to fight with when doing an s/docker/podman/ attempt |
That's hard to balance. Since it impacts Docker compat, we could make an argument for a bug fix which wouldn't require a major version. On the other hand, we don't know who is already depending on that behavior. @mattp- do you have a suggestion how to make the behavior easier to discover? Blog post, docs, etc? |
@vrothberg I think if the behavior were to change it would make sense to couple it to a major version change, not a bug fix. I'm not sure how this would be easily discoverable other than stumbling upon it. I will say back-compat aside, it was a bit unexpected for podman to leak this specific piece of config into the container without being asked. it broke in my workplace because we use tinyproxy , so our http_proxy=127.0.0.1, which of course did not work in container. maybe that's unlikely for other users that are behind a corporate proxy. |
Issue Description
outside of the difference in behavior with docker; it seems like strange behavior to pass down at runtime. setting http_proxy in container.conf would be more sensible; but taking the shell's proxy var could lead to unexpected failure.
Steps to reproduce the issue
see above excerpt
Describe the results you received
Describe the results you received
Describe the results you expected
Describe the results you expected
podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
No
Additional environment details
Additional environment details
Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting
The text was updated successfully, but these errors were encountered: