-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Implement tls-verify switch in libpod API #16491
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rhatdan The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
LGTM |
As far as I can tell, this PR does no change the default behaviour of not allowing pulling from http, correct? |
The default behavior must not change. Docker doesn't disable TLS verification by default either as it would be a huge security risk. |
Platform string `schema:"platform"` | ||
TLSVerify bool `schema:"tlsVerify"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the Docker API having that parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rhatdan the Docker API doesn't have such a parameter. I don't think this PR is needed.
So far, I cannot see how this is fixing the issue. Docker doesn't have a CLI/parameter switch to turn off TLS verification. It's configured locally, see https://docs.docker.com/registry/insecure/#deploy-a-plain-http-registry, so testcontainers should be dropping a |
Looks like docker has a special case for localhost hardcoded, that's why it works without any configuration. // loadInsecureRegistries loads insecure registries to config
func (config *serviceConfig) loadInsecureRegistries(registries []string) error {
// Localhost is by default considered as an insecure registry. This is a
// stop-gap for people who are running a private registry on localhost.
registries = append(registries, "127.0.0.0/8") |
Great catch, @SoMuchForSubtlety! @mtrmac WDYT? Should c/image follow that example? |
|
Thanks, @mtrmac! Should we recommend configuring @SoMuchForSubtlety, what do you think? |
It seems to me that if we should recommend that without qualification, we should also ship that configuration by default … which brings the question full circle. Alternatively, recommend it for single-user workstations; that would probably be more correct but I don’t know where we would document it so that people read it. |
It's currently not possible to allow localhost without specifying a port. The following config yields the error [[registry]]
prefix = "localhost"
insecure = true This config works, but only for the specified port, and the tests use randomly assigned ports. [[registry]]
location = "localhost:123123"
insecure = true |
Huh?
is expected to work, and seems to work for me manually modifying the existing unit tests. If it doesn’t work, please file a c/image bug with a reproducer. |
Seems to be a known // FIXME: allow config authors to always use Prefix.
// https://github.com/containers/image/pull/1191#discussion_r610622495
if !strings.HasPrefix(reg.Prefix, "*.") && reg.Location == "" {
return &InvalidRegistries{s: "invalid condition: location is unset and prefix is not in the format: *.example.com"}
} |
@mtrmac set the |
Good point, that’s true. |
… and that weakens my argument that users can already set this in |
Could we turn this into an RFE for registries.conf? For instance, to allow matching for any port? |
Very generally speaking there the concern there is maintaining a comprehensible “closest match” ordering between the registry entries. In this instance, I think a new I don’t know that this resolves the question about having a built-in default — but making that config possible seems with a |
@mtrmac since it's a special case one way or another: Would do you think of a boolean option "unsafe_localhost_insecure=true"? |
( Where would that option live? As a special case in But really I’m uninformed and undecided at this point. Should this be a built-in default? I’m almost sure we have had that discussion before, both about |
SGTM
Yes, I had registries.conf in mind.
I had a simple boolean in mind. False unless set in registries.conf. The code treating insecure can deal with it if the domain is localhost. A general host:anyPort would certainly be cool but I am concerned about the time it may consume. I think our books are quite full at the moment. |
Closing but we should continue the design discussion and then move the issue over to c/image. |
Why is this closed from a Podman point of view. Currently |
It claims to fix #16486 but is the wrong approach.
Shouldn't that change the libpod endpoint? This PR changes the compat one. |
Ok I will reopen to fix the libpod endpoint. |
A friendly reminder that this PR had no activity for 30 days. |
@rhatdan shall we close? |
No I hope to get back to this one. |
A friendly reminder that this PR had no activity for 30 days. |
containers#16486 Signed-off-by: Daniel J Walsh <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rhatdan, the compat
endpoint does not support a tlsVerify
parameter. podman-remote
uses the libpod
specific /images/pull
endpoint.
I don't think the code change has an effect.
@rhatdan, friendly ping. |
Signed-off-by: Daniel J Walsh [email protected]
Does this PR introduce a user-facing change?