However, a local scan, where the rootfs has been unpacked to /tmp fails:
$ check-payload scan -V 4.16 local --path /tmp/rhacm-volsync-rhel9/unpacked-rootfs/
...
I0610 15:37:42.807182 22948 scan.go:429] "scanning failed" image="" path="/usr/local/bin/diskrsync" error="go binary does not contain required symbol(s)" component="" tag="" rpm="" status="failed"
---- Failure Report
+--------------------------+-----------------------------------------------+
| EXECUTABLE NAME | STATUS |
+--------------------------+-----------------------------------------------+
| /usr/local/bin/diskrsync | go binary does not contain required symbol(s) |
+--------------------------+-----------------------------------------------+
The local scan does not match the rules in the exception file:
$ grep -B5 /usr/local/bin/diskrsync dist/releases/4.16/config.toml
# VolSync packages diskrsync which uses x/crypto/blake2b for local hashing only
# for comparing blocks of data (non-cryptographic)
# Actual network transfer is handled by the ssh executable in the image
[[payload.volsync-container.ignore]]
error = "ErrGoMissingSymbols"
files = ["/usr/local/bin/diskrsync"]
[[payload.volsync-container.ignore]]
error = "ErrNotDynLinked"
files = ["/usr/local/bin/diskrsync"]
[[payload.volsync-container.ignore]]
error = "ErrLibcryptoMissing"
files = ["/usr/local/bin/diskrsync"]
I think this is due to the component not being discovered from the com.redhat.component label during a local scan.
If I'm right, maybe the payload could be discovered via skopeo inspect instead of podman. Or maybe a new flag can be created for scan local so users can specify what component to use to look for the exception rules.
Yes, the scan local seems to require to set the config files explictly by the config command line parameter like
--config /home/dholler/src/github/dominikholler/check-payload/config.toml
check-payload scan local
is not able to match payload* exception rules as entered inconfig.toml
or the toml files underdist/releases
.Using the
scan image
command that relies on podman does work:However, a local scan, where the rootfs has been unpacked to /tmp fails:
The local scan does not match the rules in the exception file:
I think this is due to the
component
not being discovered from thecom.redhat.component
label during a local scan.If I'm right, maybe the payload could be discovered via
skopeo inspect
instead of podman. Or maybe a new flag can be created forscan local
so users can specify what component to use to look for the exception rules.