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

[ashnamehrotra]

What kind of request is this?

None

What is your request or suggestion?

copacetic/pkg/pkgmgr/dpkg.go

Line 81 in d648155

// TODO: support qualifying image name with designated repository

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 (#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"?