[REQ] Add support for qualifying image name with designated repository

[ashnamehrotra]

What kind of request is this?

None

What is your request or suggestion?

https://github.com/project-copacetic/copacetic/blob/d648155f5424a9f4cb13acd7209195846791873b/pkg/pkgmgr/dpkg.go#L81

Turning copacetic TODO comments into issues from https://docs.google.com/spreadsheets/d/1XwNj1J6e2FrUhlqaIsV10l8_tgov7WodlkvpNZXYZMU/edit#gid=1386834576.

Are you willing to submit PRs to contribute to this feature request?

• [ ] Yes, I am willing to implement it.

[Manoramsharma]

Hi @ashnamehrotra,

I have explored how Copa operates as a CLI tool that directly patches container images based on the vulnerabilities identified in scanning reports, such as those provided by tools like Trivy. After going through the full documentation, I was inspired to delve deeper into the project's codebase.

Regarding this issue, I have come up with potential changes that can accomplish our motive to add qualifying image name with designated repository support.

Proposed Changes

1. Update the Config Structure in pkg/types/unversioned/types.go:

   type Config struct {
      Arch       string `json:"arch"`
      Repository string `json:"repository"`  // New field for repository URL or identifier
   }

2. Modify the getAPTImageName Function in pkg/pkgmgr/dpkg.go:

   func getAPTImageName(manifest *unversioned.UpdateManifest) string {
      version := manifest.Metadata.OS.Version
      if manifest.Metadata.OS.Type == "debian" {
          version = strings.Split(version, ".")[0] + "-slim"
      }
      repo := manifest.Metadata.Config.Repository
      baseImageName := fmt.Sprintf("%s:%s", manifest.Metadata.OS.Type, version)
      if repo != "" {
          baseImageName = fmt.Sprintf("%s/%s", repo, baseImageName)
      }
      log.Debugf("Using %s as basis for tooling image", baseImageName)
      return baseImageName
   }

   I am already aware about kubernetes, particularly managing resources and services that run as container applications based on deployed images and feels the need of a cli-based tool like copa that facilitates the direct patching of container images quickly without going upstream for a full rebuild. I am willing to implement this feature, if you can guide me about the further steps regarding testing the changes and other pre requisites required before making actual contribution.

   Regards

[ashnamehrotra]

Hi @Manoramsharma, thank you for the suggested changes, they look great! We are planning to address this issue through @MiahaCybersec as part of the LFX Mentorship Program (https://github.com/project-copacetic/copacetic/issues/611) if you would like to collaborate on it together and we would appreciate any future contributions!

[MiahaCybersec]

Taking a look at this now. Would it be best to add a Copa flag for end users to specify a repository if they desire, otherwise falling back on default behaviour?

[ashnamehrotra]

@MiahaCybersec Sure we can add this as a CLI flag. Since it is for the tooling image, maybe it could be a flag like "--tooling-repo"?

[ashnamehrotra]

closing since we have source policies https://project-copacetic.github.io/copacetic/website/faq#can-i-replace-the-package-repositories-in-the-image-with-my-own