buildroot/package/docker-engine, branch 2019.02-op-build

package/runc: blacklist Codesourcery ARM toolchain

2019-03-04T15:25:44+00:00

Fixes: http://autobuild.buildroot.net/results/018e309caa0fc662aa2993e47b2037fb6c569011/ This toolchain uses glibc 2.18, which does not provide O_TMPFILE support. Signed-off-by: Peter Korsgaard

runc: depend on linux headers >= 3.11 for O_TMPFILE

2019-02-27T09:05:49+00:00

Fixes: http://autobuild.buildroot.net/results/63e9d88ae5177541be463f1e2aafec59aa410479 Add dependency on headers >= 3.11 for O_TMPFILE, used by runc after the fix for CVE-2019-5736 and propagate to the reverse dependencies of runc. Notice that C library support for O_TMPFILE is also needed, which was added in glibc 2.19 and musl 0.9.15. Signed-off-by: Christian Stewart [Peter: squash series, extend commit message, mention C library dependency, fix indentation] Signed-off-by: Peter Korsgaard

docker-engine: fix runc version check warning

2019-02-12T19:21:44+00:00

Fixes the startup warning from Docker: failed to retrieve runc version: unknown output format: runc version commit ... Introduces a patch to replace the faulty version detection logic in the Docker engine. Signed-off-by: Christian Stewart Signed-off-by: Peter Korsgaard

docker-engine: bump to v18.09.2

2019-02-12T19:21:39+00:00

Signed-off-by: Christian Stewart Signed-off-by: Peter Korsgaard

package/runc: add upstream security fix for CVE-2019-5736

2019-02-12T19:04:14+00:00

The vulnerability allows a malicious container to (with minimal user interaction) overwrite the host runc binary and thus gain root-level code execution on the host. The level of user interaction is being able to run any command (it doesn't matter if the command is not attacker-controlled) as root within a container in either of these contexts: * Creating a new container using an attacker-controlled image. * Attaching (docker exec) into an existing container which the attacker had previous write access to. For more details, see the advisory: https://www.openwall.com/lists/oss-security/2019/02/11/2 The fix for this issue uses fexecve(3), which isn't available on uClibc, so add a dependency on !uclibc to runc and propagate to the reverse dependencies (containerd/docker-engine). Signed-off-by: Peter Korsgaard

packages: update sysv S* scripts to 644

2019-02-08T10:35:22+00:00

Signed-off-by: Matthew Weber Signed-off-by: Peter Korsgaard

package/docker-engine: drop unused _DAEMON option

2019-02-02T11:06:03+00:00

Since commit de336584d2 (package/docker-engine: split docker-{cli, engine}, bump to v18.09.0), the docker-engine package only builds the daemon part, and the .mk file no longer use the _DAEMON option, so drop it. Signed-off-by: Peter Korsgaard Tested-by: Christian Stewart Signed-off-by: Peter Korsgaard

package/docker-engine: add sysv init script

2019-01-31T07:33:09+00:00

Signed-off-by: Peter Korsgaard Acked-by: Christian Stewart Signed-off-by: Peter Korsgaard

package/docker-engine: split docker-{cli, engine}, bump to v18.09.0

2018-12-03T20:11:03+00:00

Docker upstream has split the Docker daemon and CLI into separate codebases: - github.com/docker/engine: daemon, "dockerd" binary - github.com/docker/cli: "docker" command line interface This commit splits the docker-engine package into docker-engine and docker-cli. Conveniently, the Docker project has begun maintaining two separate release-tagged repositories for the CLI and daemon as of v18.06-ce-rc1. Previous versions were tagged in a common "docker-ce" repository which makes compilation awkward for Buildroot, especially due to some limitations in the new Go package infrastructure. Docker repositories "engine" and "cli" recently started tagging releases. Select the latest stable release, v18.09.0. The CLI is no longer automatically included with the engine. Users will need to select BR2_PACKAGE_DOCKER_CLI to produce a both docker and dockerd target binaries. Docker CLI can be statically compiled. This enables usage of the system docker client binary to access the parent daemon API from within containers, where shared libraries are not available. While at it, drop the useless host-go dependency from docker-engine, since it's already added by the golang-package infrastructure. Signed-off-by: Christian Stewart [Thomas: drop the host-go dependency from both docker-cli and docker-engine] Signed-off-by: Thomas Petazzoni

package/docker-engine: convert to golang infrastructure

2018-03-31T18:20:02+00:00

Signed-off-by: Angelo Compagnucci [Thomas: - adapt to the changes in the golang-package infrastructure - keep the logic to support BR2_PACKAGE_DOCKER_ENGINE_STATIC_CLIENT] Signed-off-by: Thomas Petazzoni