make cli tests fail on M1 mac because extra packages are found in test images

[willmurphyscode]

What happened:

On main of syft, running make cli fails on an M1 mac because

syft/test/cli/packages_cmd_test.go

Line 107 in ddb338d

assertPackageCount(163),

,

syft/test/cli/packages_cmd_test.go

Line 116 in ddb338d

assertPackageCount(164), // packages are now deduplicated for this case

, and

syft/test/cli/packages_cmd_test.go

Line 129 in ddb338d

assertPackageCount(164), // packages are now deduplicated for this case

, find 4 extra packages.

What you expected to happen:
make cli would pass on a clean checkout.
Steps to reproduce the issue:

1. Get an M1 mac (or ARM64 Linux box?)
2. Run git clone https://github.com/anchore/syft.git syft-extra-clean && cd syft-extra-clean && make bootstrap && make build && make cli && echo 'CLI tests passed'

Anything else we need to know?:
The extra packages are:

diff /tmp/non-m1  /tmp/m1
45a46
> gpg-pubkey                   305d49d6-55b78768      rpm
55a57,58
> kernel-core                  4.18.0-193.28.1.el7    rpm
> kernel-modules               4.18.0-193.28.1.el7    rpm
133a137
> qemu-guest-agent             10:2.12.0-3.el7        rpm

HEAD is at 354c72bbf4d2a005117def777410b6d084fcd467.

Environment:

• Output of syft version:

% syft version
Application:        syft
Version:            0.79.0
JsonSchemaVersion:  7.1.4
BuildDate:          2023-04-21T13:34:06Z
GitCommit:          b2b332e8b2b66af0905e98b54ebd713a922be1a8
GitDescription:     [not provided]
Platform:           darwin/arm64
GoVersion:          go1.20.3
Compiler:           gc

• OS (e.g: cat /etc/os-release or similar):

% uname -a
Darwin <hostname> 22.4.0 Darwin Kernel Version 22.4.0: Mon Mar  6 20:59:28 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T6000 arm64

[wagoodman]

Per what @willmurphyscode is mentioning, we should be pinning these Dockerfile FROM references

syft/test/cli/test-fixtures/image-hidden-packages/Dockerfile

Line 1 in ddb338d

FROM centos:7.9.2009

. One side effect might be that we'd need to host these finalized images so that developers are only pulling images and not building test fixture images -- if we go this route (say hosting as a ghcr.io package) then we should probably have a CI workflow that owns how these fixture images get updated.

The upside of doing this is that first-time make unit wouldn't be building a bunch of images and fixtures, it would really be a set of docker pulls.

[willmurphyscode]

One side effect might be that we'd need to host these finalized images so that developers are only pulling images and not building test fixture images

I'm not sure I understand. Aren't folks building images today? (I'm trying to understand whether hosting the images ourselves is an improvement we should also do, or whether it would be made necessary by pinning these from lines to digests in a way that I don't understand.)