manifest.yaml: Add content_manifest folder to add <nvr>.json for build info

[gursewak1997]

Add content_manifests dir to have json files for build_info

[openshift-ci]

Hi @gursewak1997. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[miabbott]

/ok-to-test

[gursewak1997]

/retest

[jlebon]

You can source /etc/os-release and use OSTREE_VERSION, RHEL_VERSION, and OS_NAME directly.

[jlebon]

We can't write to /var at compose time. Maybe /usr/share/buildinfo/content_manifests? I recall we talked about adding a tmpfiles.d dropin if we really need it available under /root.

[gursewak1997]

My bad, I assumed we could write to /varand not to /root. I will go with /usr/share/buildinfo/content_manifests for now. Thanks:)

[miabbott]

Yeah, we'll need to solve the problem of landing the JSON file in the specific /root/buildinfo/content_manifests location because that's where the security scanners expect it

[cgwalters]

Where can we ask these security scanners to change? Using /root for this just conflicts with ostree today, and actually more generally would be problematic for many "image based updates" models.

Even having traditional yum/rpm write to /root is pretty ugly IMO.

[miabbott]

Where can we ask these security scanners to change? Using /root for this just conflicts with ostree today, and actually more generally would be problematic for many "image based updates" models.

Even having traditional yum/rpm write to /root is pretty ugly IMO.

I made the assumption that it was a security scanner, but in the original ticket there is a reference to just scanners, which I guess could be anything doing any kind of scanning.

Since this request came from RHT ProdSec, we'd have to follow-up with them in https://issues.redhat.com/browse/GRPA-3731

[miabbott]

I think it is fine to start working to change the security scanners, though I don't know how fast we can make that happen. Let's work with ProdSec to understand which scanners are looking for this file and see if we can get them modified.

Additionally, @ashcrow pointed out that the location of the file comes from OSBS [1][2], so we could work with OSBS to modify the location of the JSON file. Or suggest a secondary location if the first location isn't available.

But given the nature of this request, I think we have to work within the constraints of the existing tools, so we should pursue the use of tmpfiles.d to land the file in the location desired.

[1] https://github.com/containerbuildsystem/atomic-reactor/blob/master/atomic_reactor/constants.py#L200
[2] https://osbs.readthedocs.io/en/latest/users.html#image-content-manifests

[cgwalters]

There's a reason though that ostree designs the constraints it does around /usr and /var etc. We can certainly use tmpfiles.d or a custom systemd unit or whatever to write this content in /var.

But the thing is - that means that rpm-ostree rollback will mean the data in /var is out of sync with /usr.

This doesn't matter a huge amount for containers because the larger container ecosystem doesn't support in-place offline updates - it's all about either running yum update (in place, online), or just tearing down the whole container and starting a new one (Kubernetes native style).

As I commented on the ticket, because rpm-ostree natively sticks this data in the commit object today, it is versioned alongside the deployment, which means that one can easily do e.g. diffs between them, and rpm-ostree rollback will always have the right data.

(Also, data in /var is mutable by default, whereas clearly this should be immutable)

[jlebon]

To clarify, the proposal here is to make e.g. /root/buildinfo be a symlink to /usr/share/buildinfo, not to copy.
Agree though that ideally we get scanners and other producers to use the data that's already available in commit metadata.

[miabbott]

Thanks for commenting on the Jira ticket with your input. I think we all completely missed the use of rpmostree.rpmmd-repos as a solution to this problem.

However, since the current tooling is looking for the information in a specific location, I still think we have to provide the data there...somehow.

Perhaps this is hacky, but might provide a solution given the constraints:

1. postprocess script that writes out the desired JSON file at /usr/share/buildinfo/content_manifests/<nvr>.json
2. a systemd unit that runs at boot which ensures there is a /var/roothome/buildinfo/content_manifests/ directory
3. same systemd unit creates a symlink from /usr/share/buildinfo/content_manifests/<nvr>.json to /var/roothome/buildinfo/content_manifests/<nvr>.json

WDYT?

[jasinner]

I think the location of the content_manifests/.json does not have to be in /root/buildinfo, and /usr/share is fine. We can talk to our security scanning partners about the location once the content is ready.

Also, I don't think we can use the rpmostree.rpmmd-repos as is. We need to translate those repositories names to something in pulp, like the the repositories listed here, or directly to CPE (from Errata tool).

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gursewak1997

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [gursewak1997]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[gursewak1997]

/retest

[jlebon]

From #670 (comment) it seems like we don't need this.

[gursewak1997]

True but @miabbott suggested on going through with the creation of .conf file and symlinking the JSON file to /roothome.

[jlebon]

jq -r will print the string without quotes. Or you should be be able to just use $(arch) for this.

[jlebon]

I don't entirely follow the jq syntax here, though one thing to note is that the repo names need to be translated to those in https://access.redhat.com/security/data/metrics/repository-to-cpe.json which I think is missing here.

The actual set of repos we use doesn't really change that often, so for this first iteration, we could just hardcode the fact that e.g. rhel-8-baseos maps to rhel-8-for-$ARCH-baseos-rpms, rhel-8-appstream to rhel-8-for-$ARCH-appstream-rpms, etc... and error out if we get a repo name we don't know.

Maybe cleaner eventually is to make that mapping part of the repo files themselves and add a treefile option to teach rpm-ostree to extract it and generate the JSON file and potentially even validate against https://access.redhat.com/security/data/metrics/repository-to-cpe.json.

[gursewak1997]

Mapping the repo names to their pulp repo IDs (ie, "[rhel-8-baseos]" to "[rhel-8-for-x86_64-baseos-eus-rpms__8_DOT_4]") would be a bit more complex task to put in postprocess so we decided to not do that here. I have just added the given repo names for now so that we can access them when mapping them to repository-to-cpe.json
So far, we are just landing the changes to create the relevant DIR/JSON file and symlinking it to /root.

[jlebon]

Had a chat with @gursewak1997 about this. I think in the end doing this in a postprocess script is probably not the right approach. We could hardcode equivalencies here, though the second we change the repo definition files in the internal redhat-coreos repo, it'll become incorrect data. Because of this, I think this data belongs best sitting alongside the repo files.

Apart from the rpm-ostree suggestion in the comment above, another easier option is a YAML file similar to the official content_sets.yml currently in use (internal example):

# content_sets.yaml
repo_mapping:
  rhel-8-baseos:
    name: rhel-8-for-$ARCH-baseos-eus-rpms__8_DOT_4
  rhel-8-appstream:
    name: rhel-8-for-$ARCH-appstream-eus-rpms__8_DOT_4
  ...

(This would live in the redhat-coreos repo so it could be maintained atomically with the repo definitions and would be similarly copied into the workdir before builds.)

And then cosa build would check for the existence of that file and auto-generate the JSON file to inject in the OS.

[miabbott]

My understanding was that Gursewak was going to work on the tooling to generate the <nvr>.json file and we would handle the problem of the repo names separately. The last working idea was just to rename all the repos to match what is in the repository-to-cpe.json file after the tooling was in place.

The YAML mapping file would also work; either way we are going to incur some amount of manual cost to maintain that the repo names are valid according to repository-to-cpe.json.

[miabbott]

I spoke with @jlebon today and we discussed various approaches to this, but ultimately settled on the proposal that Jonathan made in his last comment:

• a YAML doc that lives alongside the repo files which maps repo names to names in repository-to-cpe.json
  • additionally should include the baseurl so we can detect when that changes
• changes to cosa build that can consume the mapping YAML doc and produce the <nvr>.json file
• (future project) CI job on openshift/release that enforces changing the mapping YAML doc when changing the repo files

@gursewak1997 if you have any additional questions/concerns, please let us know