Change:
# github.com/NYTimes/gziphandler v1.1.1 => github.com/NYTimes/gziphandler v1.1.1 github.com/NYTimes/gziphandler # github.com/PuerkitoBio/purell v1.1.1 => github.com/PuerkitoBio/purell v1.1.1 <del> ## explicit </del> github.com/PuerkitoBio/purell # github.com/PuerkitoBio/urlesc v0.0.0-20170810143723-de5bf2ad4578 => github.com/PuerkitoBio/urlesc v0.0.0-20170810143723-de5bf2ad4578 github.com/PuerkitoBio/urlesc

Discussion:
This is a proactive issue opened to explore the path forward with the module that we have been using as a dependency for in here This module is looking for a new maintainer. Discussions around the path forward, potentially eliminate the module from usage and do this operation in-house, as we use it in only one place for specific functionality. Ref Issue from repo: Slack Thread:
in kubeadm the usage of : Unicode normalization on the URL host according to "Unicode Normalization Form C". Unicode transformation to "fold" characters to canonical width on the host. the host from Unicode to ASCII (IDNA encoding, but 1 and 2 and needed due to a non-conformant x/net/idna at the time?) duplicate "//" from the URL path. the whole URL as per RFC 3986 (looks like PuerkitoBio/urlesc forks golang/net/url). IMO, we should: replace the usage of with this trimmed local version: then add a release note to the PR: we could import , and do the punycode conversion, but i do not understand why it should be kubeadm's responsibility to do that. it feels like IDNA is a host reachability problem that should be solved pre-k8s deployment. i can see this being a breaking change to users having Unicode etcd endpoints in kubeadm, but i'm hoping the same users were already aware to not rely on k8s components to manage this for them.
/sig cluster-lifecycle /area kubeadm /remove-kind bug /kind cleanup
cool, that was helpful. I'll take up on this and create a PR.
/assign
From a Cluster API perspective: It's highly unlikely from the CAPI side that we'll specify IDNA in the kubeadm config. There is a chance on CAPV (vSphere) that a host picks up the DHCP option for the domain name suffix, and that it's using an IDNA. E.g., in my home environment, i have DHCP option 15 set to , and these end up in the etcd pods as parameters, e.g. Is IDNA encoding a consideration for input in etcd's command line, or are unicode args fine?

For the public clouds, it's even more unlikely we'll hit it as the choice of domain name suffix is highly constricted to meet node identity requirements in the CPI. My own take, is that I'm not wed to keeping this around at all, I haven't seen a use case for it.
cc and for any further vsphere comments.
have you seen DHCP with IDNA domains used for external etcd with kubeadm?
unicode args should be fine, also apparently Go's HTTP stack does IDNA encoding: i will update the proposed release note above. but IMO, if one would like a domain to be encoded when passed to all the tools in the k8s stack, maybe it should be done in advance. it feels like IDNA is a host reachability problem that should be solved pre-k8s deployment. or leave it to the Go standard library to do the encoding. i saw comments that it might not be fully compliant yet, but i don't know how up to date these comments are.
/triage accepted i didn't see any PRs for this for 1.22. looks like we can update it in 1.23.
Apologies, I was a little occupied at work. But I have created the PR Please let me know if we can add this as part of 1.22.
no worries. we cannot add it in 1.22 because it's not a critical bug fix and we are in code freeze. i will comment on the PR.
looks like we should tell go-openapi/jsonreference to stop using the library too.
done. Created an issue in their repo as well and offered to create a PR if they are willing to move forward with in-sourcing the logic.
thanks!
just an FYI, the maintainers of the go-openapi have also removed the purell dependency.