go-lint checks

Signed-off-by: Griffin <[email protected]>

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`, `

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.
 

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?

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.
 
 <img title="report-driven vulnerability patching" src="/copacetic/website/img/vulnerability-patch.png" />

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
  <missing> 3 months ago CMD ["nginx" "-g" "daemon off;"] 0B buildkit.dockerfile.v0
  <missing> 3 months ago STOPSIGNAL SIGQUIT 0B buildkit.dockerfile.v0
  <missing> 3 months ago EXPOSE map[80/tcp:{}] 0B buildkit.dockerfile.v0

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.
 

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?

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.
 
 <img title="report-driven vulnerability patching" src="/copacetic/website/img/vulnerability-patch.png" />

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
  <missing> 3 months ago CMD ["nginx" "-g" "daemon off;"] 0B buildkit.dockerfile.v0
  <missing> 3 months ago STOPSIGNAL SIGQUIT 0B buildkit.dockerfile.v0
  <missing> 3 months ago EXPOSE map[80/tcp:{}] 0B buildkit.dockerfile.v0

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.
 

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?

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.
 
 <img title="report-driven vulnerability patching" src="/copacetic/website/img/vulnerability-patch.png" />

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
  <missing> 3 months ago CMD ["nginx" "-g" "daemon off;"] 0B buildkit.dockerfile.v0
  <missing> 3 months ago STOPSIGNAL SIGQUIT 0B buildkit.dockerfile.v0
  <missing> 3 months ago EXPOSE map[80/tcp:{}] 0B buildkit.dockerfile.v0

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.
 

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?

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.
 
 <img title="report-driven vulnerability patching" src="/copacetic/website/img/vulnerability-patch.png" />

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
  <missing> 3 months ago CMD ["nginx" "-g" "daemon off;"] 0B buildkit.dockerfile.v0
  <missing> 3 months ago STOPSIGNAL SIGQUIT 0B buildkit.dockerfile.v0
  <missing> 3 months ago EXPOSE map[80/tcp:{}] 0B buildkit.dockerfile.v0