Golang 1.12.12
-------------------------------
go1.12.12 (released 2019/10/17) includes fixes to the go command, runtime,
syscall and net packages. See the Go 1.12.12 milestone on our issue tracker for
details.
https://github.com/golang/go/issues?q=milestone%3AGo1.12.12
Golang 1.12.11 (CVE-2019-17596)
-------------------------------
go1.12.11 (released 2019/10/17) includes security fixes to the crypto/dsa
package. See the Go 1.12.11 milestone on our issue tracker for details.
https://github.com/golang/go/issues?q=milestone%3AGo1.12.11
[security] Go 1.13.2 and Go 1.12.11 are released
Hi gophers,
We have just released Go 1.13.2 and Go 1.12.11 to address a recently reported
security issue. We recommend that all affected users update to one of these
releases (if you're not sure which, choose Go 1.13.2).
Invalid DSA public keys can cause a panic in dsa.Verify. In particular, using
crypto/x509.Verify on a crafted X.509 certificate chain can lead to a panic,
even if the certificates don't chain to a trusted root. The chain can be
delivered via a crypto/tls connection to a client, or to a server that accepts
and verifies client certificates. net/http clients can be made to crash by an
HTTPS server, while net/http servers that accept client certificates will
recover the panic and are unaffected.
Moreover, an application might crash invoking
crypto/x509.(*CertificateRequest).CheckSignature on an X.509 certificate
request, parsing a golang.org/x/crypto/openpgp Entity, or during a
golang.org/x/crypto/otr conversation. Finally, a golang.org/x/crypto/ssh client
can panic due to a malformed host key, while a server could panic if either
PublicKeyCallback accepts a malformed public key, or if IsUserAuthority accepts
a certificate with a malformed public key.
The issue is CVE-2019-17596 and Go issue golang.org/issue/34960.
Thanks to Daniel Mandragona for discovering and reporting this issue. We'd also
like to thank regilero for a previous disclosure of CVE-2019-16276.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit f9eab1b87b)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: https://github.com/golang/go/compare/go1.12.9...go1.12.10
```
Hi gophers,
We have just released Go 1.13.1 and Go 1.12.10 to address a recently reported security issue. We recommend that all affected users update to one of these releases (if you're not sure which, choose Go 1.13.1).
net/http (through net/textproto) used to accept and normalize invalid HTTP/1.1 headers with a space before the colon, in violation of RFC 7230. If a Go server is used behind an uncommon reverse proxy that accepts and forwards but doesn't normalize such invalid headers, the reverse proxy and the server can interpret the headers differently. This can lead to filter bypasses or request smuggling, the latter if requests from separate clients are multiplexed onto the same upstream connection by the proxy. Such invalid headers are now rejected by Go servers, and passed without normalization to Go client applications.
The issue is CVE-2019-16276 and Go issue golang.org/issue/34540.
Thanks to Andrew Stucki, Adam Scarr (99designs.com), and Jan Masarik (masarik.sh) for discovering and reporting this issue.
Downloads are available at https://golang.org/dl for all supported platforms.
Alla prossima,
Filippo on behalf of the Go team
```
From the patch: 6e6f4aaf70
```
net/textproto: don't normalize headers with spaces before the colon
RFC 7230 is clear about headers with a space before the colon, like
X-Answer : 42
being invalid, but we've been accepting and normalizing them for compatibility
purposes since CL 5690059 in 2012.
On the client side, this is harmless and indeed most browsers behave the same
to this day. On the server side, this becomes a security issue when the
behavior doesn't match that of a reverse proxy sitting in front of the server.
For example, if a WAF accepts them without normalizing them, it might be
possible to bypass its filters, because the Go server would interpret the
header differently. Worse, if the reverse proxy coalesces requests onto a
single HTTP/1.1 connection to a Go server, the understanding of the request
boundaries can get out of sync between them, allowing an attacker to tack an
arbitrary method and path onto a request by other clients, including
authentication headers unknown to the attacker.
This was recently presented at multiple security conferences:
https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn
net/http servers already reject header keys with invalid characters.
Simply stop normalizing extra spaces in net/textproto, let it return them
unchanged like it does for other invalid headers, and let net/http enforce
RFC 7230, which is HTTP specific. This loses us normalization on the client
side, but there's no right answer on the client side anyway, and hiding the
issue sounds worse than letting the application decide.
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 7847c12a44)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 9a5aabdaff removed the fixed
version for this plugin, and changed it to install from "master",
which made the build non-reproducible.
This patch pins the plugin to a specific tag/release again, but allow
overriding by setting the `BUILDX_COMMIT` env-var.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit ffee8a345b)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Noticed this failing in internal e2e tests on CentOS:
```
sudo docker engine activate --license /tmp/docker.lic
unable to determine the installed engine version. Specify which engine image to update with --engine-image: open /var/lib/docker-engine/distribution_based_engine.json: no such file or directory
```
Looks lik 09b3ac888d changed the name of this
file from `distribution_based_engine-ce.json` to `distribution_based_engine.json`
(without `-ce` suffix) for the `.deb` packages, but did not update
the RPM packages accordingly.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 77878ffa48)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.12.8 (released 2019/08/13) includes security fixes to the net/http and net/url packages.
See the Go 1.12.8 milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.12.8
- net/http: Denial of Service vulnerabilities in the HTTP/2 implementation
net/http and golang.org/x/net/http2 servers that accept direct connections from untrusted
clients could be remotely made to allocate an unlimited amount of memory, until the program
crashes. Servers will now close connections if the send queue accumulates too many control
messages.
The issues are CVE-2019-9512 and CVE-2019-9514, and Go issue golang.org/issue/33606.
Thanks to Jonathan Looney from Netflix for discovering and reporting these issues.
This is also fixed in version v0.0.0-20190813141303-74dc4d7220e7 of golang.org/x/net/http2.
net/url: parsing validation issue
- url.Parse would accept URLs with malformed hosts, such that the Host field could have arbitrary
suffixes that would appear in neither Hostname() nor Port(), allowing authorization bypasses
in certain applications. Note that URLs with invalid, not numeric ports will now return an error
from url.Parse.
The issue is CVE-2019-14809 and Go issue golang.org/issue/29098.
Thanks to Julian Hector and Nikolai Krein from Cure53, and Adi Cohen (adico.me) for discovering
and reporting this issue.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 9f5da37431)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The dh_installman script calls "man" and captures its output to convert manpages
to utf8:
8523120dcc/dh_installman (L298-L316)
however, on minimized Ubuntu systems, man is overridden by a script that outputs
a warning message ("This system has been minimized by removing packages and
content ..").
As a result, all man-pages were be overwritten by that message.
This patch restores the actual `man` command before building to
work around this issue.
addresses docker/for-linux#639
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit e52fa49844)
version 2.9 is really old; this sets the same minimal version
as is used for the containerd.io package
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit a246b19b07)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
On some distros we were encountering errors where `$1` was not being populated
for the 'pre' and 'posttrans' rpm macros, upon closer inspection it
isn't exactly clear why the pre and posttrans macro scripts were exactly
useful since the `%systemd_postun_with_restart` does exactly what those
scripts were doing.
I've tidied up the systemd macros to use `docker.service` instead of
`docker` which seems to function as we'd expect.
taken from downstream commit 62d8413b550659a0b5318346ee2e3d7e4a50bfe1
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit bece037752)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- systemd-units -> systemd (taken from 8bb1f0a7a395dfd979cd410b26ef47e55433de32)
- some wording changes (taken from a8c522a7c22c34dc354e91941377a4aadc3ddc4c)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit ffcd2256e4)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Eli Uriegas
Sebastiaan van Stijn
docker-unir[bot]
Andrew Hsu
Tibor Vass
Zuhayr Elahi
Jintao Zhang
Nick Danyluk
Silvin Lubecki