Description of problem: Product Security need a way determining which rpms are in an RHCOS release. We need it so that we can inform customers when a CVE fix is being released of OCP4. We think that Errata Tool is the best place to inform customers about CVE fixes which are included in a product update. However at the moment Errata Tool doesn't have a tool which can read the rpm data published in brew, [1]. We think that adding the commitmeta.json to the container payload will make it easier for Errata Tool, and other tools such as OpenSCAP to determine the content in the machine-os-content container image, without having to unpack the OSTree content, or inspect brew directly. [1] http://download.eng.bos.redhat.com/brewroot/packages/rhcos/410.8.20190619.1/004427/images/commitmeta.json Since we are recording this information in brew, it seems like it would be easy to also add it to the actual container being shipped. We could add it directly to the image as a file, or add it to the container metadata. Version-Release number of selected component (if applicable): 410.8.20190619.1 How reproducible: Get the machine-os-content image and inspect the contents for commitmeta.json Steps to Reproduce: 1. Query the release image for the OCP version: $ ./oc adm release info --image-for="" quay.io/openshift-release-dev/ocp-release:4.1.3 | grep machine-os-content machine-os-content sha256:70dfb630dadbc16f15507c01b6d7783c8cb5140ac280ff518296c5ec00484afc 2. Inspect the container metadata for the machine-os-content image $ ./oc image info quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:70dfb630dadbc16f15507c01b6d7783c8cb5140ac280ff518296c5ec00484afc | grep version version=410.8.20190619.1 3. Pull the machine-os-content image $ sudo podman pull --authfile=pull-secret.txt quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:70dfb630dadbc16f15507c01b6d7783c8cb5140ac280ff518296c5ec00484afc 4. Create a container from the image: $ sudo podman create --net=none --name machine-os-content quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:70dfb630dadbc16f15507c01b6d7783c8cb5140ac280ff518296c5ec00484afc 5. Mount the filesystem for the image: $ sudo podman mount machine-os-content 6. Look for the commitmeta.json $ sudo find /var/lib/containers/storage/overlay/13d586883a9e663128dff327eec36069ec5c05eb2f868c606cede95f295e3927/merged -name commitmeta.json Actual results: No commitmeta.json exists Expected results: commitmeta exists in the image, or in the container metadata. Additional Information: This rpm content from commitmeta.json is indexed on the release pages for OCP4, ie: https://releases-rhcos.cloud.privileged.psi.redhat.com/contents.html?release=410.8.20190619.1
Not completely against including the commitmeta.json, but I think having it easily linked and exported from the release browser (and now possibly relied upon by more external services) means that we've essentially made public an interface we never really planned to (and I'm partly to blame for this -- https://github.com/coreos/coreos-assembler/pull/226). Although the rpmostree.rpmdb.pkglist key is unlikely to change, other keys have in the past (esp. in the "layered" version of the commit metadata). It would be pretty easy for cosa to export a package list in a stable format for external consumers (could just match the rpmostree.rpmdb.pkglist format as it is today). For the purposes here, a stable way to retrieve the RPM list is `rpm-ostree db list --repo $mount/srv/repo $commit`, which doesn't require you to extract the rpmdb at all. (This approach also means we don't have two sources of truth in the container, and leaves the door open for having multiple commits in the same container).
Jason, I think including this information is fine, especially if it will make errata tool use easier for folks. Following on to Jonathan's idea, would you be fine with us exporting a package list in the container or is `commitmeta.json` literally needed?
Hi Steve, Exporting a package list in the container is fine. We still need to come up with a way to use the information in Errata Tool, or LightBlue, so not fixed on the commitmeta.json format yet. Regards
Pre work: - https://github.com/coreos/coreos-assembler/pull/655 - https://github.com/coreos/coreos-assembler/pull/657
PR: https://github.com/coreos/coreos-assembler/pull/661
PR merged. Backport to 4.2: https://github.com/coreos/coreos-assembler/pull/665
Backport merged
Tried to verify this with the latest 4.2 builds coming out of ART, but looks like the coreos-assembler image being used to build RHCOS didn't have the necessary commit. I've kicked off a new build of coreos-assembler and will check again after an RHCOS build has completed using the new coreos-assembler.
Verified with 4.2.0-0.nightly-2019-07-30-073644 ``` $ oc image info -a ~/openshift-cluster-installs/all-the-pull-secrets.json $(oc adm release info -a ~/openshift-cluster-installs/all-the-pull-secrets.json --image-for=machine-os-content registry.svc.ci.openshift.org/ocp/release:4.2.0-0.nightly-2019-07-30-073644) Name: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:7f0c22748a2b3c75c4e42feab15bfec2e585caa9c99192a5d4a6fc1909f6d812 Media Type: application/vnd.docker.distribution.manifest.v2+json Created: 10h ago Image Size: 616.9MB in 1 layers Layers: 616.9MB sha256:281c3d60f8a892dfde706ede8a96e2030af90d3294723a9a27202e7bc7c080d6 OS: linux Arch: amd64 Entrypoint: /noentry Labels: com.coreos.ostree-commit=bd734a82d9764c5244082c9b0b10ae7e9678ef92d7be89a75d28a5732242e986 version=42.80.20190730.0 $ sudo podman pull --authfile /home/miabbott/openshift-cluster-installs/all-the-pull-secrets.json quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:7f0c22748a2b3c75c4e42feab15bfec2e585caa9c99192a5d4a6fc1909f6d812 Trying to pull quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:7f0c22748a2b3c75c4e42feab15bfec2e585caa9c99192a5d4a6fc1909f6d812...Getting image source signatures Copying blob 281c3d60f8a8 done Copying config 760529ea88 done Writing manifest to image destination Storing signatures 760529ea88e54db8facfbb5f4e43a5a953088d270eb1870d571e77c09e4e56a4 $ sudo podman create --net=none --name machine-os-content 760529ea88e54db8facfbb5f4e43a5a953088d270eb1870d571e77c09e4e56a4 b178a980c34535e8346dd4daa191627e9f29d5c28dc9775e45ce52b838e58f84 $ sudo podman mount b178a980c34535e8346dd4daa191627e9f29d5c28dc9775e45ce52b838e58f84 /var/lib/containers/storage/overlay/4fd41da6c27b7c36c81fc9961e897606fb74085a94e7f8c3c1e6bcfa1469cfb0/merged $ sudo find /var/lib/containers/storage/overlay/4fd41da6c27b7c36c81fc9961e897606fb74085a94e7f8c3c1e6bcfa1469cfb0/merged -name pkglist.txt /var/lib/containers/storage/overlay/4fd41da6c27b7c36c81fc9961e897606fb74085a94e7f8c3c1e6bcfa1469cfb0/merged/pkglist.txt $ sudo head /var/lib/containers/storage/overlay/4fd41da6c27b7c36c81fc9961e897606fb74085a94e7f8c3c1e6bcfa1469cfb0/merged/pkglist.txt NetworkManager-1:1.14.0-14.el8.x86_64 NetworkManager-libnm-1:1.14.0-14.el8.x86_64 acl-2.2.53-1.el8.x86_64 adcli-0.8.2-2.el8.x86_64 afterburn-4.1.1-3.rhaos4.2.el8.x86_64 attr-2.4.48-3.el8.x86_64 audit-3.0-0.10.20180831git0047a6c.el8.x86_64 audit-libs-3.0-0.10.20180831git0047a6c.el8.x86_64 avahi-libs-0.7-19.el8.x86_64 basesystem-11-5.el8.noarch ```
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:2922