Edited second paragraph under ### Daemon configuration file to change "regardless their value" to "regardless of their value"
Signed-off-by: Jake Stokes <contactjake@developerjake.com>
(cherry picked from commit 9335690a66)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds the new aliases that were added in 9b54d860cd
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 08a794dc0c)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 1e3622c50c moved the generator code
to a subdirectory, but forgot to update the markdown version of this script.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 37f234fbe7)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.19.8 (released 2023-04-04) includes security fixes to the go/parser,
html/template, mime/multipart, net/http, and net/textproto packages, as well as
bug fixes to the linker, the runtime, and the time package. See the Go 1.19.8
milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.19.8+label%3ACherryPickApproved
full diff: https://github.com/golang/go/compare/go1.19.7...go1.19.8
Further details from the announcement on the mailing list:
We have just released Go versions 1.20.3 and 1.19.8, minor point releases.
These minor releases include 4 security fixes following the security policy:
- go/parser: infinite loop in parsing
Calling any of the Parse functions on Go source code which contains `//line`
directives with very large line numbers can cause an infinite loop due to
integer overflow.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
This is CVE-2023-24537 and Go issue https://go.dev/issue/59180.
- html/template: backticks not treated as string delimiters
Templates did not properly consider backticks (`) as Javascript string
delimiters, and as such did not escape them as expected. Backticks are
used, since ES6, for JS template literals. If a template contained a Go
template action within a Javascript template literal, the contents of the
action could be used to terminate the literal, injecting arbitrary Javascript
code into the Go template.
As ES6 template literals are rather complex, and themselves can do string
interpolation, we've decided to simply disallow Go template actions from being
used inside of them (e.g. "var a = {{.}}"), since there is no obviously safe
way to allow this behavior. This takes the same approach as
github.com/google/safehtml. Template.Parse will now return an Error when it
encounters templates like this, with a currently unexported ErrorCode with a
value of 12. This ErrorCode will be exported in the next major release.
Users who rely on this behavior can re-enable it using the GODEBUG flag
jstmpllitinterp=1, with the caveat that backticks will now be escaped. This
should be used with caution.
Thanks to Sohom Datta, Manipal Institute of Technology, for reporting this issue.
This is CVE-2023-24538 and Go issue https://go.dev/issue/59234.
- net/http, net/textproto: denial of service from excessive memory allocation
HTTP and MIME header parsing could allocate large amounts of memory, even when
parsing small inputs.
Certain unusual patterns of input data could cause the common function used to
parse HTTP and MIME headers to allocate substantially more memory than
required to hold the parsed headers. An attacker can exploit this behavior to
cause an HTTP server to allocate large amounts of memory from a small request,
potentially leading to memory exhaustion and a denial of service.
Header parsing now correctly allocates only the memory required to hold parsed
headers.
Thanks to Jakob Ackermann (@das7pad) for discovering this issue.
This is CVE-2023-24534 and Go issue https://go.dev/issue/58975.
- net/http, net/textproto, mime/multipart: denial of service from excessive resource consumption
Multipart form parsing can consume large amounts of CPU and memory when
processing form inputs containing very large numbers of parts. This stems from
several causes:
mime/multipart.Reader.ReadForm limits the total memory a parsed multipart form
can consume. ReadForm could undercount the amount of memory consumed, leading
it to accept larger inputs than intended. Limiting total memory does not
account for increased pressure on the garbage collector from large numbers of
small allocations in forms with many parts. ReadForm could allocate a large
number of short-lived buffers, further increasing pressure on the garbage
collector. The combination of these factors can permit an attacker to cause an
program that parses multipart forms to consume large amounts of CPU and
memory, potentially resulting in a denial of service. This affects programs
that use mime/multipart.Reader.ReadForm, as well as form parsing in the
net/http package with the Request methods FormFile, FormValue,
ParseMultipartForm, and PostFormValue.
ReadForm now does a better job of estimating the memory consumption of parsed
forms, and performs many fewer short-lived allocations.
In addition, mime/multipart.Reader now imposes the following limits on the
size of parsed forms:
Forms parsed with ReadForm may contain no more than 1000 parts. This limit may
be adjusted with the environment variable GODEBUG=multipartmaxparts=. Form
parts parsed with NextPart and NextRawPart may contain no more than 10,000
header fields. In addition, forms parsed with ReadForm may contain no more
than 10,000 header fields across all parts. This limit may be adjusted with
the environment variable GODEBUG=multipartmaxheaders=.
Thanks to Jakob Ackermann for discovering this issue.
This is CVE-2023-24536 and Go issue https://go.dev/issue/59153.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This moves all the terminal writing to a goroutine that updates the
terminal periodically.
In our MITM copier we just use an atomic to add to the total number of
bytes read/written, the goroutine reads the total and updates the
terminal as needed.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit eb392ff4ce)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Only show progress updates after a time threshold has elapsed in order
to reduce the number of writes to the terminal.
This improves readability of the progress.
Also moves cursor show/hide into the progress printer to reduce chances
if messing up the user's terminal in case of cancellation.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 90b7bc36d4)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This just makes it easier to reason about what is happening.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit efd011b793)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
- Instead of rewriting the entire line every time only clear and write
the parts that changed.
- Hide the cursor while writing progress
Both these things make the progress updates significantly easier to
read.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit ccae6e9299)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This fixes a case where a non-tty will have control characters + the log
line for every single read operation.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit f27927d934)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
These were deprecated in 6c400a9c2009bba9376ad61ab59c04c1ad675871 (docker 19.03),
but the "Deprecated:" comments were missing a newline before them.
While most IDEs will detect such comments as "deprecated", pkg.go.dev and linters
will ignore them, which may result in users not being aware of them being deprecated.
This patch;
- Fixes the "Deprecated:" comments.
- Changes the var aliases to functions, which is slightly more boilerplating,
but makes sure the functions are documented as "function", instead of shown
in the "variables" section on pkg.go.dev.
- Adds some punctuation and adds "doc links", which allows readers to navigate
to related content on pkg.go.dev.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 817897f891)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We can slightly improve plugins listing by spawning a
goroutine for each iteration.
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
(cherry picked from commit 89583b92b7)
# Conflicts:
# vendor.mod
# vendor/modules.txt
We are currently loading plugin command stubs for every
invocation which still has a significant performance hit.
With this change we are doing this operation only if cobra
completion arg request is found.
- 20.10.23: `docker --version` takes ~15ms
- 23.0.1: `docker --version` takes ~93ms
With this change `docker --version` takes ~9ms
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
(cherry picked from commit c39c711a18)
looks like this one was forgotten to be updated :)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit e4436853e8)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The comment was not formatted correctly, and because of that not picked up as
being deprecated.
updates b4ca1c7368
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit e3fa7280ad)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Includes a security fix for crypto/elliptic (CVE-2023-24532).
> go1.19.7 (released 2023-03-07) includes a security fix to the crypto/elliptic
> package, as well as bug fixes to the linker, the runtime, and the crypto/x509
> and syscall packages. See the Go 1.19.7 milestone on our issue tracker for
> details.
https://go.dev/doc/devel/release#go1.19.minor
From the announcement:
> We have just released Go versions 1.20.2 and 1.19.7, minor point releases.
>
> These minor releases include 1 security fixes following the security policy:
>
> - crypto/elliptic: incorrect P-256 ScalarMult and ScalarBaseMult results
>
> The ScalarMult and ScalarBaseMult methods of the P256 Curve may return an
> incorrect result if called with some specific unreduced scalars (a scalar larger
> than the order of the curve).
>
> This does not impact usages of crypto/ecdsa or crypto/ecdh.
>
> This is CVE-2023-24532 and Go issue https://go.dev/issue/58647.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 23da1cec6c)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Make the error more specific by stating that it's caused by a specific
environment variable and not an environment as a whole.
Also don't escape the variable to make it more readable.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit 012b77952e)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
On Windows, ignore all variables that start with "=" when building an
environment variables map for stack.
For MS-DOS compatibility cmd.exe can set some special environment
variables that start with a "=" characters, which breaks the general
assumption that the first encountered "=" separates a variable name from
variable value and causes trouble when parsing.
These variables don't seem to be documented anywhere, but they are
described by some third-party sources and confirmed empirically on my
Windows installation.
Useful sources:
https://devblogs.microsoft.com/oldnewthing/20100506-00/?p=14133https://ss64.com/nt/syntax-variables.html
Known variables:
- `=ExitCode` stores the exit code returned by external command (in hex
format)
- `=ExitCodeAscii` - same as above, except the value is the ASCII
representation of the code (so exit code 65 (0x41) becomes 'A').
- `=::=::\` and friends - store drive specific working directory.
There is one env variable for each separate drive letter that was
accessed in the shell session and stores the working directory for that
specific drive.
The general format for these is:
`=<DRIVE_LETTER>:=<CWD>` (key=`=<DRIVE_LETTER>:`, value=`<CWD>`)
where <CWD> is a working directory for the drive that is assigned to
the letter <DRIVE_LETTER>
A couple of examples:
`=C:=C:\some\dir` (key: `=C:`, value: `C:\some\dir`)
`=D:=D:\some\other\dir` (key: `=C:`, value: `C:\some\dir`)
`=Z:=Z:\` (key: `=Z:`, value: `Z:\`)
`=::=::\` is the one that seems to be always set and I'm not exactly
sure what this one is for (what's drive `::`?). Others are set as
soon as you CD to a path on some drive. Considering that you start a
cmd.exe also has some working directory, there are 2 of these on start.
All these variables can be safely ignored because they can't be
deliberately set by the user, their meaning is only relevant to the
cmd.exe session and they're all are related to the MS-DOS/Batch feature
that are irrelevant for us.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit a47058bbd5)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit 8bc1aaceae)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Laura Brehm
Jake Stokes
CrazyMax
Sebastiaan van Stijn
Sebastiaan van Stijn
Brian Goff
CrazyMax
Paweł Gronowski
Jacopo Rigoli