This fix tries to address issues raised in moby/moby#44346.
The max-concurrent-downloads and max-concurrent-uploads limits are applied for the whole engine and not for each pull/push command.
Signed-off-by: Luis Henrique Mulinari <luis.mulinari@gmail.com>
This restores compatibility with go1.18, which was broken since commit;
c062238ea4
cmd.Environ() is new in go1.19, and not needed for this specific case.
Without this, trying to use this package in code that uses go1.18 will fail;
builder/remotecontext/git/gitutils.go:216:23: cmd.Environ undefined (type *exec.Cmd has no field or method Environ)
Changing to use `os.Environ()` instead restores compatibility with go1.18
Full diff: f9cb47a052...5aac513617
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This example was mounting `/dev/zero` as `/dev/nulo` inside the container.
The `nulo` name was intended to be a "made up / custom" name, but various
readers thought it to be a typo for `/dev/null`.
This patch updates the example to use `/dev/foobar` as name, which should
make it more clear that it's a custom name.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 955c1f881a
(v17.12.0) replaced detection of support for multiple lowerdirs (as required by
overlay2) to not depend on the kernel version. The `overlay2.override_kernel_check`
was still used to print a warning that older kernel versions may not have full
support.
After this, e226aea280
(v20.10, but backported to v19.03.7) removed uses of the option altogether.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
> Security options with `:` as a separator are deprecated and will be completely unsupported in 17.04, use `=` instead.
Signed-off-by: Felix Geyer <debfx@fobos.de>
From the mailing list:
We have just released Go versions 1.19.2 and 1.18.7, minor point releases.
These minor releases include 3 security fixes following the security policy:
- archive/tar: unbounded memory consumption when reading headers
Reader.Read did not set a limit on the maximum size of file headers.
A maliciously crafted archive could cause Read to allocate unbounded
amounts of memory, potentially causing resource exhaustion or panics.
Reader.Read now limits the maximum size of header blocks to 1 MiB.
Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting this issue.
This is CVE-2022-2879 and Go issue https://go.dev/issue/54853.
- net/http/httputil: ReverseProxy should not forward unparseable query parameters
Requests forwarded by ReverseProxy included the raw query parameters from the
inbound request, including unparseable parameters rejected by net/http. This
could permit query parameter smuggling when a Go proxy forwards a parameter
with an unparseable value.
ReverseProxy will now sanitize the query parameters in the forwarded query
when the outbound request's Form field is set after the ReverseProxy.Director
function returns, indicating that the proxy has parsed the query parameters.
Proxies which do not parse query parameters continue to forward the original
query parameters unchanged.
Thanks to Gal Goldstein (Security Researcher, Oxeye) and
Daniel Abeles (Head of Research, Oxeye) for reporting this issue.
This is CVE-2022-2880 and Go issue https://go.dev/issue/54663.
- regexp/syntax: limit memory used by parsing regexps
The parsed regexp representation is linear in the size of the input,
but in some cases the constant factor can be as high as 40,000,
making relatively small regexps consume much larger amounts of memory.
Each regexp being parsed is now limited to a 256 MB memory footprint.
Regular expressions whose representation would use more space than that
are now rejected. Normal use of regular expressions is unaffected.
Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting this issue.
This is CVE-2022-41715 and Go issue https://go.dev/issue/55949.
View the release notes for more information: https://go.dev/doc/devel/release#go1.19.2
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
gofumpt provides a supserset of gofmt / go fmt, but not every developer may have
it installed, so for situations where it's not available, fall back to gofmt.
As our code has been formatted with gofumpt already, in most cases contributions
will follow those formatting rules, but in some cases there may be a difference,
which would already be flagged by manual code review, but let's also enable the
gofumpt linter.
With this change, `make fmt` will use gofumpt is available; gofumpt has been
added to the dev-container, so `make -f docker.Makefile fmt` will always use it.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Looks like the linter uses an explicit -lang, which (for go1.19)
results in some additional formatting for octal values.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The existing `remove()` was unused, and using that as name makes it more
consistent with the metadata-store. Also renaming `removeAllEndpointData`
to just `removeEndpoint`, as it's part of the TLS-store, which should already
make it clear it's about (TLS)data.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
There's no reason to stop listing contexts if a context does not exist
while iterating over the directories,
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Go conventions are for interfaces to be defined on the receiver side,
and for producers to return concrete types. This patch changes the
constructor to return a concrete type.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The package defined various special errors; these errors existed for two reasons;
- being able to distinguish "not found" errors from other errors (as "not found"
errors can be ignored in various cases).
- to be able to update the context _name_ in the error message after the error
was created. This was needed in cases where the name was not available at the
location where the error was produced (e.g. only the "id" was present), and
the helpers to detect "not found" errors did not support wrapped errors (so
wrapping the error with a "name" could break logic); a `setContextName` interface
and corresponding `patchErrContextName()` utility was created for this (which
was a "creative", but not very standard approach).
This patch:
- Removes the special error-types, replacing them with errdefs definitions (which
is a more common approach in our code-base to detect error types / classes).
- Removes the internal utilities for error-handling, and deprecates the exported
utilities (to allow external consumers to adjust their code).
- Some errors have been enriched with detailed information (which may be useful
for debugging / problem solving).
- Note that in some cases, `patchErrContextName()` was called, but the code
producing the error would never return a `setContextName` error, so would
never update the error message.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This test was depending on the fact that contextDir's are a string,
and for the test is was using the context _name_ as a pseudo-ID.
This patch updates the test to be more explicit where ID's and where
names are used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This allows callers to just pass the name, and handle the conversion to ID and
path internally. This also fixes a test which incorrectly used "names" as
pseudo-IDs.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit cbec75e2f3 updated `runDocker()` to load
plugin-stubs before `processAliases()` was executed. As a result, plugin
stubs were considered as "builtin commands", causing the alias verification
to fail;
Without alias installed:
```bash
docker version
Client:
Version: 22.06.0-beta.0-140-g3dad26ca2.m
API version: 1.42
Go version: go1.19.1
Git commit: 3dad26ca2
Built: Wed Sep 28 22:36:09 2022
OS/Arch: darwin/arm64
Context: default
...
```
After running `docker buildx install`;
```bash
./build/docker buildx install
cat ~/.docker/config.json
{
"aliases": {
"builder": "buildx"
}
}
./build/docker version
not allowed to alias with builtin "buildx" as target
```
This patch moves loading the stubs _after_ the call to `processAliases()`, so
that verification passes. As an extra precaution, the `processAliases()` function
is also updated to exclude plugin-stub commands.
Note that cbec75e2f3 also introduced a performance
regression, which may be related to the early loading of plugins (and creating
stubs); it looks like various other code locations may also be loading plugins,
for example `tryPluginRun()` calls `pluginmanager.PluginRunCommand()`, which
also traverses plugin directories.
We should look under what circumstances the plugin stub-commands are actually
needed, and make sure that they're only created in those situations.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Luis Henrique Mulinari
Sebastiaan van Stijn
CrazyMax
Sebastiaan van Stijn
Tianon Gravi
Bishal Das
mspiess
Felix Geyer