This function returned the whole response, but we already handled the
warnings included in the response as part of the function. All consumers
of this function only used the container-ID, so let's simplify and return
just that (it's a non-exported func, so we can change the signature again
if we really need it).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add a const for the name of the environment-variable we accept, so
that we can document its purpose in code.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use the default proxy, to assist with vanity domains mis-behaving, but keep
a fallback for situations where we need to get modules from GitHub directly.
This should hopefully help with the gopkg.in/yaml.v2 domain often going AWOL;
#14 245.9 gopkg.in/yaml.v2@v2.4.0: unrecognized import path "gopkg.in/yaml.v2": reading https://gopkg.in/yaml.v2?go-get=1: 502 Bad Gateway
#14 245.9 server response: Cannot obtain refs from GitHub: cannot talk to GitHub: Get https://github.com/go-yaml/yaml.git/info/refs?service=git-upload-pack: write tcp 10.131.9.188:60820->140.82.121.3:443: write: broken pipe
curl 'https://gopkg.in/yaml.v2?go-get=1'
Cannot obtain refs from GitHub: cannot talk to GitHub: Get https://github.com/go-yaml/yaml.git/info/refs?service=git-upload-pack: write tcp 10.131.9.188:60820->140.82.121.3:443: write: broken pipe
From the Go documentation; https://go.dev/ref/mod#goproxy-protocol
> List elements may be separated by commas (,) or pipes (|), which determine error
> fallback behavior. When a URL is followed by a comma, the go command falls back
> to later sources only after a 404 (Not Found) or 410 (Gone) response. When a URL
> is followed by a pipe, the go command falls back to later sources after any error,
> including non-HTTP errors such as timeouts. This error handling behavior lets a
> proxy act as a gatekeeper for unknown modules. For example, a proxy could respond
> with error 403 (Forbidden) for modules not on an approved list (see Private proxy
> serving private modules).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
the "golang.org/x/sys/execabs" package was introduced to address a security
issue on Windows, and changing the default behavior of os/exec was considered
a breaking change. go1.19 applied the behavior that was previously implemented
in the execabs package;
from the release notes: https://go.dev/doc/go1.19#os-exec-path
> Command and LookPath no longer allow results from a PATH search to be found
> relative to the current directory. This removes a common source of security
> problems but may also break existing programs that depend on using, say,
> exec.Command("prog") to run a binary named prog (or, on Windows, prog.exe)
> in the current directory. See the os/exec package documentation for information
> about how best to update such programs.
>
> On Windows, Command and LookPath now respect the NoDefaultCurrentDirectoryInExePath
> environment variable, making it possible to disable the default implicit search
> of “.” in PATH lookups on Windows systems.
With those changes, we no longer need to use the execabs package, and we can
switch back to os/exec.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit c846428cb6 added proxies to the
example `daemon.json`, based on the implementation that was added in
427c7cc5f8.
However, a follow-up pull request changed the proxy-configuration in`daemon.json`
to nest the configuration in a "proxies" struct, and the documentation was
not updated accordingly; see:
101dafd049
This patch fixes the example.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The AuFS and (legacy) overlay storage drivers have been deprecated and
removed, so remove them from the completion scripts.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The AuFS storage driver was deprecated and has been removed, so let's
update the test-fixtures accordingly.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit de8b696ed6 removed the patch
releases from the deprecation doc, but when we switched to the
SemVer(ish) format for v23.0, we accidentally added them back.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
None of the client will return the old error-types, so there's no need
to keep the compatibility code. We can consider deprecating this function
in favor of the errdefs equivalent this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Sebastiaan van Stijn
Sebastiaan van Stijn
David Karlsson
Bjorn Neergaard
A. Lester Buck III