feat: store --namespace as APK maintainer field

[lyoung-confluent]

Recently, we ran into an issue where trivy was incorrectly reporting vulnerabilities in a package/image we built via melange/apko. Upon further investigation, this issue was occurring because we were building a package with the same name and similar versioning as an existing Wolfi/Chainguard package. As a result, trivy was incorrectly matching the package name from Wolfi's security.json against this internal package and subsequently reporting vulnerabilities.

We looked into "fixing" trivy's APK package logic to only extract APK packages that were installed from the Wolfi repository, however we discovered that /lib/apk/db/installed doesn't actually contain enough information to make this determination.

This PR attempts to improve this situation in the future by passing along the --namespace build parameter (which is already embedded in the generated SBOM for each package) as the maintainer field for each APK package as well. This information will eventually get included via the m: field in /lib/apk/db/installed when the APK package is installed via apk-tools or apko.

A future change to trivy or other vulnerability scanners could be made to only extract the packages that either don't have a maintainer field (for backwards compatibility), or have a value of wolfi (or chainguard) only.

Arguably the packager field would be a more appropriate location for this value however that field does not end up in /lib/apk/db/installed, only a subset of fields are stored there: https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/package.c?ref_type=heads#L880

[xnox]

@lyoung-confluent note packages sboms should have Originator already in /var/lib/db/sbom/ for each package.

Can you please check that it is there, and it is different for self built package; versus the ones that came from Wolfi / Chainguard?

Independent of the package sbom stuff, we typically do say that one can detect stuff out of the installed database; thus yeah we should probably do this bit.

Separately, to get this change out quicker, we could also patch apko to check the namespace of the packages and automatically emit it for each package as it is generating the installed db (note that installed db is synthesised by apko at image build time, rather than being crated with apk add during base image builds). Please check if there is support for that in apko and/or consider contributing that.

[jonjohnsonjr]

Arguably the packager field would be a more appropriate location for this value however that field does not end up in /lib/apk/db/installed, only a subset of fields are stored there

Blah, I was going to suggest this. Another option might be to use a URL that points to a site hosted under wolfi.dev or chainguard.dev (with some kind of landing page, if we're feeling fancy). In alpine these point to the upstream project. I'm not sure if that is worse or better than overloading maintainer.

[xnox]

Arguably the packager field would be a more appropriate location for this value however that field does not end up in /lib/apk/db/installed, only a subset of fields are stored there

Blah, I was going to suggest this. Another option might be to use a URL that points to a site hosted under wolfi.dev or chainguard.dev (with some kind of landing page, if we're feeling fancy). In alpine these point to the upstream project. I'm not sure if that is worse or better than overloading maintainer.

there have been requests to populate uri: in melange files, and have those propagate for upstream identification.
Does that end up in this field? I need to find that and check all that.

[jonjohnsonjr]

Does that end up in this field? I need to find that and check all that.

$ crane export alpine@sha256:483f502c0e6aff6d80a807f25d3f88afa40439c29fdd2d21a0912e0f42db842a | tar -Ox lib/apk/db/installed | grep "U:"   
U:https://git.alpinelinux.org/cgit/aports/tree/main/alpine-baselayout
U:https://git.alpinelinux.org/cgit/aports/tree/main/alpine-baselayout
U:https://alpinelinux.org
U:https://alpinelinux.org
U:https://gitlab.alpinelinux.org/alpine/apk-tools
U:https://busybox.net/
U:https://busybox.net/
U:https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
U:https://www.openssl.org/
U:https://www.openssl.org/
U:https://musl.libc.org/
U:https://musl.libc.org/
U:https://wiki.gentoo.org/wiki/Hardened/PaX_Utilities
U:https://busybox.net/
U:https://zlib.net/

[xnox]

https://wiki.alpinelinux.org/wiki/Apk_spec#Installed_Database_V2

This file is located at /lib/apk/db/installed. The installed file is a plaintext file of the same format as APKINDEX (contained in APKINDEX.tar.gz).

https://wiki.alpinelinux.org/wiki/Apk_spec#APKINDEX_Format

U: - url (corresponds to url in PKGINFO)
m: - maintainer (corresponds to maintainer in PKGINFO), optional

However, there is this thing too in https://wiki.alpinelinux.org/wiki/Apk_spec#Installed_Database_V2:

s: - repository tag, optional, this will be set if the package is tagged to a repository in the world file (ex: linux@testing)

what does repository tag mean? can that be "glibc@wolfi" ?

[xnox]

ooooh, i wonder if apko should do this: https://wiki.alpinelinux.org/wiki/Repositories#Repository_pinning

specify our repositories as tagged; generate world file as tagged; and then things pin to our repository and version.

[jonjohnsonjr]

specify our repositories as tagged; generate world file as tagged; and then things pin to our repository and version

Yeah I've talked to matt a little bit about how this would solve a bunch of problems for us, but we'd need to fix a bunch of things downstream of apko that assume locked config looks like $package=$version. I can write something up.

[xnox]

specify our repositories as tagged; generate world file as tagged; and then things pin to our repository and version

Yeah I've talked to matt a little bit about how this would solve a bunch of problems for us, but we'd need to fix a bunch of things downstream of apko that assume locked config looks like $package=$version. I can write something up.

can it be both pinned to version and tagged $package=$version@wolfi ?