From 6a7d018a720617a5ddf7b19fd8c8c1e88357331a Mon Sep 17 00:00:00 2001 From: Griffin Date: Sat, 12 Oct 2024 08:09:08 +0530 Subject: [PATCH] go-lint checks Signed-off-by: Griffin --- pkg/pkgmgr/dpkg.go | 2 +- website/versioned_docs/version-v0.1.x/design.md | 2 +- website/versioned_docs/version-v0.1.x/faq.md | 2 +- website/versioned_docs/version-v0.1.x/introduction.md | 2 +- website/versioned_docs/version-v0.1.x/quick-start.md | 2 +- website/versioned_docs/version-v0.2.x/design.md | 2 +- website/versioned_docs/version-v0.2.x/faq.md | 2 +- website/versioned_docs/version-v0.2.x/introduction.md | 2 +- website/versioned_docs/version-v0.2.x/quick-start.md | 2 +- website/versioned_docs/version-v0.3.x/design.md | 2 +- website/versioned_docs/version-v0.3.x/faq.md | 2 +- website/versioned_docs/version-v0.3.x/introduction.md | 2 +- website/versioned_docs/version-v0.3.x/quick-start.md | 2 +- website/versioned_docs/version-v0.4.x/design.md | 2 +- website/versioned_docs/version-v0.4.x/faq.md | 2 +- website/versioned_docs/version-v0.4.x/introduction.md | 2 +- website/versioned_docs/version-v0.4.x/quick-start.md | 2 +- website/versioned_docs/version-v0.5.x/design.md | 2 +- website/versioned_docs/version-v0.5.x/faq.md | 2 +- website/versioned_docs/version-v0.5.x/introduction.md | 2 +- website/versioned_docs/version-v0.5.x/quick-start.md | 2 +- website/versioned_docs/version-v0.6.x/design.md | 2 +- website/versioned_docs/version-v0.6.x/faq.md | 2 +- website/versioned_docs/version-v0.6.x/introduction.md | 2 +- website/versioned_docs/version-v0.6.x/quick-start.md | 2 +- website/versioned_docs/version-v0.7.x/design.md | 2 +- website/versioned_docs/version-v0.7.x/faq.md | 2 +- website/versioned_docs/version-v0.7.x/introduction.md | 2 +- website/versioned_docs/version-v0.7.x/quick-start.md | 2 +- website/versioned_docs/version-v0.8.x/design.md | 2 +- website/versioned_docs/version-v0.8.x/faq.md | 2 +- website/versioned_docs/version-v0.8.x/introduction.md | 2 +- website/versioned_docs/version-v0.8.x/quick-start.md | 2 +- 33 files changed, 33 insertions(+), 33 deletions(-) diff --git a/pkg/pkgmgr/dpkg.go b/pkg/pkgmgr/dpkg.go index 94e4fa3a..8f18810e 100644 --- a/pkg/pkgmgr/dpkg.go +++ b/pkg/pkgmgr/dpkg.go @@ -401,7 +401,7 @@ func (dm *dpkgManager) unpackAndMergeUpdates(ctx context.Context, updates unvers return nil, nil, fmt.Errorf("unable to marshal dm.packageInfo %w", err) } - updated = updated.Run( + updated = updated.Run( llb.AddEnv("PACKAGES_PRESENT", string(jsonPackageData)), llb.Args([]string{ `bash`, `-c`, ` diff --git a/website/versioned_docs/version-v0.1.x/design.md b/website/versioned_docs/version-v0.1.x/design.md index 31f642bb..de3a8566 100644 --- a/website/versioned_docs/version-v0.1.x/design.md +++ b/website/versioned_docs/version-v0.1.x/design.md @@ -16,7 +16,7 @@ title: Design The design of copa arises from the application of those tenets to the observed issues in previous efforts directly update container images via rebasing, for example, the experimental [`crane rebase`](https://github.com/google/go-containerregistry/blob/main/cmd/crane/rebase.md): -- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. +- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt-get install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. To avoid breaking integration with the existing container ecosystem, copa patches the filesystem bundle as a whole instead of as a collection of layers so that the resulting image state is consistent. This strategy also allows copa to patch vulnerabilties introduced at any layer in the image, including OS packages added in the app layers that is not addressed by a simple rebase. It also supports the core tenet of supporting patching without requiring coordination with all the publishers of the base images that a given image transitively depends on. diff --git a/website/versioned_docs/version-v0.1.x/faq.md b/website/versioned_docs/version-v0.1.x/faq.md index 5bb1839e..5345a1f1 100644 --- a/website/versioned_docs/version-v0.1.x/faq.md +++ b/website/versioned_docs/version-v0.1.x/faq.md @@ -4,7 +4,7 @@ title: FAQ ## What kind of vulnerabilities can Copa patch? -Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). +Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt-get` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). ## What kind of vulnerabilities can Copa not patch? diff --git a/website/versioned_docs/version-v0.1.x/introduction.md b/website/versioned_docs/version-v0.1.x/introduction.md index 0fe5ada6..70d578a3 100644 --- a/website/versioned_docs/version-v0.1.x/introduction.md +++ b/website/versioned_docs/version-v0.1.x/introduction.md @@ -27,7 +27,7 @@ In addition to filling the operational gap not met by left-shift security practi The `copa` tool is an extensible engine that: 1. Parses the needed update packages from the container image’s vulnerability report produced by a scanner like Trivy. New adapters can be written to accommodate more report formats. -2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt, apk, etc. New adapters can be written to support more package managers. +2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt-get, apk, etc. New adapters can be written to support more package managers. 3. Applies the resulting update binaries to the container image using buildkit. diff --git a/website/versioned_docs/version-v0.1.x/quick-start.md b/website/versioned_docs/version-v0.1.x/quick-start.md index 85129994..14eeb743 100644 --- a/website/versioned_docs/version-v0.1.x/quick-start.md +++ b/website/versioned_docs/version-v0.1.x/quick-start.md @@ -70,7 +70,7 @@ This sample illustrates how to patch containers using vulnerability reports with ```bash $ docker history docker.io/library/nginx:1.21.6-patched IMAGE CREATED CREATED BY SIZE COMMENT - a372df41e06d 1 minute ago mount / from exec sh -c apt install --no-ins… 26.1MB buildkit.exporter.image.v0 + a372df41e06d 1 minute ago mount / from exec sh -c apt-get install --no-ins… 26.1MB buildkit.exporter.image.v0 3 months ago CMD ["nginx" "-g" "daemon off;"] 0B buildkit.dockerfile.v0 3 months ago STOPSIGNAL SIGQUIT 0B buildkit.dockerfile.v0 3 months ago EXPOSE map[80/tcp:{}] 0B buildkit.dockerfile.v0 diff --git a/website/versioned_docs/version-v0.2.x/design.md b/website/versioned_docs/version-v0.2.x/design.md index 31f642bb..de3a8566 100644 --- a/website/versioned_docs/version-v0.2.x/design.md +++ b/website/versioned_docs/version-v0.2.x/design.md @@ -16,7 +16,7 @@ title: Design The design of copa arises from the application of those tenets to the observed issues in previous efforts directly update container images via rebasing, for example, the experimental [`crane rebase`](https://github.com/google/go-containerregistry/blob/main/cmd/crane/rebase.md): -- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. +- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt-get install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. To avoid breaking integration with the existing container ecosystem, copa patches the filesystem bundle as a whole instead of as a collection of layers so that the resulting image state is consistent. This strategy also allows copa to patch vulnerabilties introduced at any layer in the image, including OS packages added in the app layers that is not addressed by a simple rebase. It also supports the core tenet of supporting patching without requiring coordination with all the publishers of the base images that a given image transitively depends on. diff --git a/website/versioned_docs/version-v0.2.x/faq.md b/website/versioned_docs/version-v0.2.x/faq.md index 5bb1839e..5345a1f1 100644 --- a/website/versioned_docs/version-v0.2.x/faq.md +++ b/website/versioned_docs/version-v0.2.x/faq.md @@ -4,7 +4,7 @@ title: FAQ ## What kind of vulnerabilities can Copa patch? -Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). +Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt-get` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). ## What kind of vulnerabilities can Copa not patch? diff --git a/website/versioned_docs/version-v0.2.x/introduction.md b/website/versioned_docs/version-v0.2.x/introduction.md index 0fe5ada6..70d578a3 100644 --- a/website/versioned_docs/version-v0.2.x/introduction.md +++ b/website/versioned_docs/version-v0.2.x/introduction.md @@ -27,7 +27,7 @@ In addition to filling the operational gap not met by left-shift security practi The `copa` tool is an extensible engine that: 1. Parses the needed update packages from the container image’s vulnerability report produced by a scanner like Trivy. New adapters can be written to accommodate more report formats. -2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt, apk, etc. New adapters can be written to support more package managers. +2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt-get, apk, etc. New adapters can be written to support more package managers. 3. Applies the resulting update binaries to the container image using buildkit. diff --git a/website/versioned_docs/version-v0.2.x/quick-start.md b/website/versioned_docs/version-v0.2.x/quick-start.md index 85129994..14eeb743 100644 --- a/website/versioned_docs/version-v0.2.x/quick-start.md +++ b/website/versioned_docs/version-v0.2.x/quick-start.md @@ -70,7 +70,7 @@ This sample illustrates how to patch containers using vulnerability reports with ```bash $ docker history docker.io/library/nginx:1.21.6-patched IMAGE CREATED CREATED BY SIZE COMMENT - a372df41e06d 1 minute ago mount / from exec sh -c apt install --no-ins… 26.1MB buildkit.exporter.image.v0 + a372df41e06d 1 minute ago mount / from exec sh -c apt-get install --no-ins… 26.1MB buildkit.exporter.image.v0 3 months ago CMD ["nginx" "-g" "daemon off;"] 0B buildkit.dockerfile.v0 3 months ago STOPSIGNAL SIGQUIT 0B buildkit.dockerfile.v0 3 months ago EXPOSE map[80/tcp:{}] 0B buildkit.dockerfile.v0 diff --git a/website/versioned_docs/version-v0.3.x/design.md b/website/versioned_docs/version-v0.3.x/design.md index 31f642bb..de3a8566 100644 --- a/website/versioned_docs/version-v0.3.x/design.md +++ b/website/versioned_docs/version-v0.3.x/design.md @@ -16,7 +16,7 @@ title: Design The design of copa arises from the application of those tenets to the observed issues in previous efforts directly update container images via rebasing, for example, the experimental [`crane rebase`](https://github.com/google/go-containerregistry/blob/main/cmd/crane/rebase.md): -- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. +- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt-get install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. To avoid breaking integration with the existing container ecosystem, copa patches the filesystem bundle as a whole instead of as a collection of layers so that the resulting image state is consistent. This strategy also allows copa to patch vulnerabilties introduced at any layer in the image, including OS packages added in the app layers that is not addressed by a simple rebase. It also supports the core tenet of supporting patching without requiring coordination with all the publishers of the base images that a given image transitively depends on. diff --git a/website/versioned_docs/version-v0.3.x/faq.md b/website/versioned_docs/version-v0.3.x/faq.md index 5bb1839e..5345a1f1 100644 --- a/website/versioned_docs/version-v0.3.x/faq.md +++ b/website/versioned_docs/version-v0.3.x/faq.md @@ -4,7 +4,7 @@ title: FAQ ## What kind of vulnerabilities can Copa patch? -Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). +Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt-get` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). ## What kind of vulnerabilities can Copa not patch? diff --git a/website/versioned_docs/version-v0.3.x/introduction.md b/website/versioned_docs/version-v0.3.x/introduction.md index 0fe5ada6..70d578a3 100644 --- a/website/versioned_docs/version-v0.3.x/introduction.md +++ b/website/versioned_docs/version-v0.3.x/introduction.md @@ -27,7 +27,7 @@ In addition to filling the operational gap not met by left-shift security practi The `copa` tool is an extensible engine that: 1. Parses the needed update packages from the container image’s vulnerability report produced by a scanner like Trivy. New adapters can be written to accommodate more report formats. -2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt, apk, etc. New adapters can be written to support more package managers. +2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt-get, apk, etc. New adapters can be written to support more package managers. 3. Applies the resulting update binaries to the container image using buildkit. diff --git a/website/versioned_docs/version-v0.3.x/quick-start.md b/website/versioned_docs/version-v0.3.x/quick-start.md index d83a67c8..31af24b8 100644 --- a/website/versioned_docs/version-v0.3.x/quick-start.md +++ b/website/versioned_docs/version-v0.3.x/quick-start.md @@ -70,7 +70,7 @@ This sample illustrates how to patch containers using vulnerability reports with ```bash $ docker history docker.io/library/nginx:1.21.6-patched IMAGE CREATED CREATED BY SIZE COMMENT - a372df41e06d 1 minute ago mount / from exec sh -c apt install --no-ins… 26.1MB buildkit.exporter.image.v0 + a372df41e06d 1 minute ago mount / from exec sh -c apt-get install --no-ins… 26.1MB buildkit.exporter.image.v0 3 months ago CMD ["nginx" "-g" "daemon off;"] 0B buildkit.dockerfile.v0 3 months ago STOPSIGNAL SIGQUIT 0B buildkit.dockerfile.v0 3 months ago EXPOSE map[80/tcp:{}] 0B buildkit.dockerfile.v0 diff --git a/website/versioned_docs/version-v0.4.x/design.md b/website/versioned_docs/version-v0.4.x/design.md index 31f642bb..de3a8566 100644 --- a/website/versioned_docs/version-v0.4.x/design.md +++ b/website/versioned_docs/version-v0.4.x/design.md @@ -16,7 +16,7 @@ title: Design The design of copa arises from the application of those tenets to the observed issues in previous efforts directly update container images via rebasing, for example, the experimental [`crane rebase`](https://github.com/google/go-containerregistry/blob/main/cmd/crane/rebase.md): -- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. +- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt-get install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. To avoid breaking integration with the existing container ecosystem, copa patches the filesystem bundle as a whole instead of as a collection of layers so that the resulting image state is consistent. This strategy also allows copa to patch vulnerabilties introduced at any layer in the image, including OS packages added in the app layers that is not addressed by a simple rebase. It also supports the core tenet of supporting patching without requiring coordination with all the publishers of the base images that a given image transitively depends on. diff --git a/website/versioned_docs/version-v0.4.x/faq.md b/website/versioned_docs/version-v0.4.x/faq.md index 5bb1839e..5345a1f1 100644 --- a/website/versioned_docs/version-v0.4.x/faq.md +++ b/website/versioned_docs/version-v0.4.x/faq.md @@ -4,7 +4,7 @@ title: FAQ ## What kind of vulnerabilities can Copa patch? -Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). +Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt-get` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). ## What kind of vulnerabilities can Copa not patch? diff --git a/website/versioned_docs/version-v0.4.x/introduction.md b/website/versioned_docs/version-v0.4.x/introduction.md index 0fe5ada6..70d578a3 100644 --- a/website/versioned_docs/version-v0.4.x/introduction.md +++ b/website/versioned_docs/version-v0.4.x/introduction.md @@ -27,7 +27,7 @@ In addition to filling the operational gap not met by left-shift security practi The `copa` tool is an extensible engine that: 1. Parses the needed update packages from the container image’s vulnerability report produced by a scanner like Trivy. New adapters can be written to accommodate more report formats. -2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt, apk, etc. New adapters can be written to support more package managers. +2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt-get, apk, etc. New adapters can be written to support more package managers. 3. Applies the resulting update binaries to the container image using buildkit. diff --git a/website/versioned_docs/version-v0.4.x/quick-start.md b/website/versioned_docs/version-v0.4.x/quick-start.md index 854cf178..f78a7b42 100644 --- a/website/versioned_docs/version-v0.4.x/quick-start.md +++ b/website/versioned_docs/version-v0.4.x/quick-start.md @@ -115,7 +115,7 @@ This sample illustrates how to patch containers using vulnerability reports with ```bash $ docker history mcr.microsoft.com/oss/nginx/nginx:1.21.6-patched IMAGE CREATED CREATED BY SIZE COMMENT - a372df41e06d 1 minute ago mount / from exec sh -c apt install --no-ins… 26.1MB buildkit.exporter.image.v0 + a372df41e06d 1 minute ago mount / from exec sh -c apt-get install --no-ins… 26.1MB buildkit.exporter.image.v0 3 months ago CMD ["nginx" "-g" "daemon off;"] 0B buildkit.dockerfile.v0 3 months ago STOPSIGNAL SIGQUIT 0B buildkit.dockerfile.v0 3 months ago EXPOSE map[80/tcp:{}] 0B buildkit.dockerfile.v0 diff --git a/website/versioned_docs/version-v0.5.x/design.md b/website/versioned_docs/version-v0.5.x/design.md index 31f642bb..de3a8566 100644 --- a/website/versioned_docs/version-v0.5.x/design.md +++ b/website/versioned_docs/version-v0.5.x/design.md @@ -16,7 +16,7 @@ title: Design The design of copa arises from the application of those tenets to the observed issues in previous efforts directly update container images via rebasing, for example, the experimental [`crane rebase`](https://github.com/google/go-containerregistry/blob/main/cmd/crane/rebase.md): -- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. +- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt-get install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. To avoid breaking integration with the existing container ecosystem, copa patches the filesystem bundle as a whole instead of as a collection of layers so that the resulting image state is consistent. This strategy also allows copa to patch vulnerabilties introduced at any layer in the image, including OS packages added in the app layers that is not addressed by a simple rebase. It also supports the core tenet of supporting patching without requiring coordination with all the publishers of the base images that a given image transitively depends on. diff --git a/website/versioned_docs/version-v0.5.x/faq.md b/website/versioned_docs/version-v0.5.x/faq.md index 44f028ac..ab6857ab 100644 --- a/website/versioned_docs/version-v0.5.x/faq.md +++ b/website/versioned_docs/version-v0.5.x/faq.md @@ -4,7 +4,7 @@ title: FAQ ## What kind of vulnerabilities can Copa patch? -Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). +Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt-get` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). ## What kind of vulnerabilities can Copa not patch? diff --git a/website/versioned_docs/version-v0.5.x/introduction.md b/website/versioned_docs/version-v0.5.x/introduction.md index 0fe5ada6..70d578a3 100644 --- a/website/versioned_docs/version-v0.5.x/introduction.md +++ b/website/versioned_docs/version-v0.5.x/introduction.md @@ -27,7 +27,7 @@ In addition to filling the operational gap not met by left-shift security practi The `copa` tool is an extensible engine that: 1. Parses the needed update packages from the container image’s vulnerability report produced by a scanner like Trivy. New adapters can be written to accommodate more report formats. -2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt, apk, etc. New adapters can be written to support more package managers. +2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt-get, apk, etc. New adapters can be written to support more package managers. 3. Applies the resulting update binaries to the container image using buildkit. diff --git a/website/versioned_docs/version-v0.5.x/quick-start.md b/website/versioned_docs/version-v0.5.x/quick-start.md index 53554a5b..06e1159d 100644 --- a/website/versioned_docs/version-v0.5.x/quick-start.md +++ b/website/versioned_docs/version-v0.5.x/quick-start.md @@ -109,7 +109,7 @@ This sample illustrates how to patch containers using vulnerability reports with ```bash $ docker history docker.io/library/nginx:1.21.6-patched IMAGE CREATED CREATED BY SIZE COMMENT - a372df41e06d 1 minute ago mount / from exec sh -c apt install --no-ins… 26.1MB buildkit.exporter.image.v0 + a372df41e06d 1 minute ago mount / from exec sh -c apt-get install --no-ins… 26.1MB buildkit.exporter.image.v0 3 months ago CMD ["nginx" "-g" "daemon off;"] 0B buildkit.dockerfile.v0 3 months ago STOPSIGNAL SIGQUIT 0B buildkit.dockerfile.v0 3 months ago EXPOSE map[80/tcp:{}] 0B buildkit.dockerfile.v0 diff --git a/website/versioned_docs/version-v0.6.x/design.md b/website/versioned_docs/version-v0.6.x/design.md index 31f642bb..de3a8566 100644 --- a/website/versioned_docs/version-v0.6.x/design.md +++ b/website/versioned_docs/version-v0.6.x/design.md @@ -16,7 +16,7 @@ title: Design The design of copa arises from the application of those tenets to the observed issues in previous efforts directly update container images via rebasing, for example, the experimental [`crane rebase`](https://github.com/google/go-containerregistry/blob/main/cmd/crane/rebase.md): -- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. +- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt-get install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. To avoid breaking integration with the existing container ecosystem, copa patches the filesystem bundle as a whole instead of as a collection of layers so that the resulting image state is consistent. This strategy also allows copa to patch vulnerabilties introduced at any layer in the image, including OS packages added in the app layers that is not addressed by a simple rebase. It also supports the core tenet of supporting patching without requiring coordination with all the publishers of the base images that a given image transitively depends on. diff --git a/website/versioned_docs/version-v0.6.x/faq.md b/website/versioned_docs/version-v0.6.x/faq.md index 44f028ac..ab6857ab 100644 --- a/website/versioned_docs/version-v0.6.x/faq.md +++ b/website/versioned_docs/version-v0.6.x/faq.md @@ -4,7 +4,7 @@ title: FAQ ## What kind of vulnerabilities can Copa patch? -Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). +Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt-get` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). ## What kind of vulnerabilities can Copa not patch? diff --git a/website/versioned_docs/version-v0.6.x/introduction.md b/website/versioned_docs/version-v0.6.x/introduction.md index 0fe5ada6..70d578a3 100644 --- a/website/versioned_docs/version-v0.6.x/introduction.md +++ b/website/versioned_docs/version-v0.6.x/introduction.md @@ -27,7 +27,7 @@ In addition to filling the operational gap not met by left-shift security practi The `copa` tool is an extensible engine that: 1. Parses the needed update packages from the container image’s vulnerability report produced by a scanner like Trivy. New adapters can be written to accommodate more report formats. -2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt, apk, etc. New adapters can be written to support more package managers. +2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt-get, apk, etc. New adapters can be written to support more package managers. 3. Applies the resulting update binaries to the container image using buildkit. diff --git a/website/versioned_docs/version-v0.6.x/quick-start.md b/website/versioned_docs/version-v0.6.x/quick-start.md index fb76e10e..41793fb9 100644 --- a/website/versioned_docs/version-v0.6.x/quick-start.md +++ b/website/versioned_docs/version-v0.6.x/quick-start.md @@ -65,7 +65,7 @@ This sample illustrates how to patch containers using vulnerability reports with ```bash $ docker history docker.io/library/nginx:1.21.6-patched IMAGE CREATED CREATED BY SIZE COMMENT - 262dacfeb193 About a minute ago mount / from exec sh -c apt install --no-ins… 41.1MB buildkit.exporter.image.v0 + 262dacfeb193 About a minute ago mount / from exec sh -c apt-get install --no-ins… 41.1MB buildkit.exporter.image.v0 20 months ago /bin/sh -c #(nop) CMD ["nginx" "-g" "daemon… 0B 20 months ago /bin/sh -c #(nop) STOPSIGNAL SIGQUIT 0B 20 months ago /bin/sh -c #(nop) EXPOSE 80 0B diff --git a/website/versioned_docs/version-v0.7.x/design.md b/website/versioned_docs/version-v0.7.x/design.md index 31f642bb..de3a8566 100644 --- a/website/versioned_docs/version-v0.7.x/design.md +++ b/website/versioned_docs/version-v0.7.x/design.md @@ -16,7 +16,7 @@ title: Design The design of copa arises from the application of those tenets to the observed issues in previous efforts directly update container images via rebasing, for example, the experimental [`crane rebase`](https://github.com/google/go-containerregistry/blob/main/cmd/crane/rebase.md): -- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. +- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt-get install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. To avoid breaking integration with the existing container ecosystem, copa patches the filesystem bundle as a whole instead of as a collection of layers so that the resulting image state is consistent. This strategy also allows copa to patch vulnerabilties introduced at any layer in the image, including OS packages added in the app layers that is not addressed by a simple rebase. It also supports the core tenet of supporting patching without requiring coordination with all the publishers of the base images that a given image transitively depends on. diff --git a/website/versioned_docs/version-v0.7.x/faq.md b/website/versioned_docs/version-v0.7.x/faq.md index 18db4851..75152429 100644 --- a/website/versioned_docs/version-v0.7.x/faq.md +++ b/website/versioned_docs/version-v0.7.x/faq.md @@ -4,7 +4,7 @@ title: FAQ ## What kind of vulnerabilities can Copa patch? -Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). +Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt-get` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). ## What kind of vulnerabilities can Copa not patch? diff --git a/website/versioned_docs/version-v0.7.x/introduction.md b/website/versioned_docs/version-v0.7.x/introduction.md index 0fe5ada6..70d578a3 100644 --- a/website/versioned_docs/version-v0.7.x/introduction.md +++ b/website/versioned_docs/version-v0.7.x/introduction.md @@ -27,7 +27,7 @@ In addition to filling the operational gap not met by left-shift security practi The `copa` tool is an extensible engine that: 1. Parses the needed update packages from the container image’s vulnerability report produced by a scanner like Trivy. New adapters can be written to accommodate more report formats. -2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt, apk, etc. New adapters can be written to support more package managers. +2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt-get, apk, etc. New adapters can be written to support more package managers. 3. Applies the resulting update binaries to the container image using buildkit. diff --git a/website/versioned_docs/version-v0.7.x/quick-start.md b/website/versioned_docs/version-v0.7.x/quick-start.md index db8ecd71..29694947 100644 --- a/website/versioned_docs/version-v0.7.x/quick-start.md +++ b/website/versioned_docs/version-v0.7.x/quick-start.md @@ -117,7 +117,7 @@ This guide illustrates how to patch outdated containers with `copa`. ```bash $ docker history $IMAGE-patched IMAGE CREATED CREATED BY SIZE COMMENT - 262dacfeb193 About a minute ago mount / from exec sh -c apt install --no-ins… 41.1MB buildkit.exporter.image.v0 + 262dacfeb193 About a minute ago mount / from exec sh -c apt-get install --no-ins… 41.1MB buildkit.exporter.image.v0 20 months ago /bin/sh -c #(nop) CMD ["nginx" "-g" "daemon… 0B 20 months ago /bin/sh -c #(nop) STOPSIGNAL SIGQUIT 0B 20 months ago /bin/sh -c #(nop) EXPOSE 80 0B diff --git a/website/versioned_docs/version-v0.8.x/design.md b/website/versioned_docs/version-v0.8.x/design.md index 31f642bb..de3a8566 100644 --- a/website/versioned_docs/version-v0.8.x/design.md +++ b/website/versioned_docs/version-v0.8.x/design.md @@ -16,7 +16,7 @@ title: Design The design of copa arises from the application of those tenets to the observed issues in previous efforts directly update container images via rebasing, for example, the experimental [`crane rebase`](https://github.com/google/go-containerregistry/blob/main/cmd/crane/rebase.md): -- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. +- Rebasing requires that all actors involved in creation of the image are coordinated so that some layers can be switched out without breaking the image. Attempting to switch out layers in the container overlay structure is brittle because most existing containers are created by writing over shared configuration files and data stores in base images. For example, an `apt-get install` during image creation will overwrite the dpkg `status` file in the base image, which will mask any package updates in a rebased layer. Since many existing container scanners rely on the reported package status to find vulnerable package versions, this can cause new vulnerabilities to not be reported or for patched binaries not to be recognized by the scanners. To avoid breaking integration with the existing container ecosystem, copa patches the filesystem bundle as a whole instead of as a collection of layers so that the resulting image state is consistent. This strategy also allows copa to patch vulnerabilties introduced at any layer in the image, including OS packages added in the app layers that is not addressed by a simple rebase. It also supports the core tenet of supporting patching without requiring coordination with all the publishers of the base images that a given image transitively depends on. diff --git a/website/versioned_docs/version-v0.8.x/faq.md b/website/versioned_docs/version-v0.8.x/faq.md index 4ec90358..308e1042 100644 --- a/website/versioned_docs/version-v0.8.x/faq.md +++ b/website/versioned_docs/version-v0.8.x/faq.md @@ -4,7 +4,7 @@ title: FAQ ## What kind of vulnerabilities can Copa patch? -Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). +Copa is capable of patching "OS level" vulnerabilities. This includes packages (like `openssl`) in the image that are managed by a package manager such as `apt-get` or `yum`. Copa is not currently capable of patching vulnerabilities at the "application level" such as Python packages or Go modules (see [below](#what-kind-of-vulnerabilities-can-copa-not-patch) for more details). ## What kind of vulnerabilities can Copa not patch? diff --git a/website/versioned_docs/version-v0.8.x/introduction.md b/website/versioned_docs/version-v0.8.x/introduction.md index 6d767464..4f1e9832 100644 --- a/website/versioned_docs/version-v0.8.x/introduction.md +++ b/website/versioned_docs/version-v0.8.x/introduction.md @@ -27,7 +27,7 @@ In addition to filling the operational gap not met by left-shift security practi The `copa` tool is an extensible engine that: 1. Parses the needed update packages from the container image’s vulnerability report produced by a scanner like Trivy. New adapters can be written to accommodate more report formats. -2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt, apk, etc. New adapters can be written to support more package managers. +2. Obtains and processes the needed update packages using the appropriate package manager tools such as apt-get, apk, etc. New adapters can be written to support more package managers. 3. Applies the resulting update binaries to the container image using buildkit. diff --git a/website/versioned_docs/version-v0.8.x/quick-start.md b/website/versioned_docs/version-v0.8.x/quick-start.md index efb4aed5..9698c655 100644 --- a/website/versioned_docs/version-v0.8.x/quick-start.md +++ b/website/versioned_docs/version-v0.8.x/quick-start.md @@ -123,7 +123,7 @@ This guide illustrates how to patch outdated containers with `copa`. ```bash $ docker history $IMAGE-patched IMAGE CREATED CREATED BY SIZE COMMENT - 262dacfeb193 About a minute ago mount / from exec sh -c apt install --no-ins… 41.1MB buildkit.exporter.image.v0 + 262dacfeb193 About a minute ago mount / from exec sh -c apt-get install --no-ins… 41.1MB buildkit.exporter.image.v0 20 months ago /bin/sh -c #(nop) CMD ["nginx" "-g" "daemon… 0B 20 months ago /bin/sh -c #(nop) STOPSIGNAL SIGQUIT 0B 20 months ago /bin/sh -c #(nop) EXPOSE 80 0B