jf scan failed to index tar file as container image and exits with an unexpected exit code

[cospeedster]

Describe the bug

jf scan failed to index tar file downloaded with skopeo as container image. I've tried that with oci and v2 format (see logs below). Also the command exits with Scan completed successfully. and exit code 0 wich is unexpected.

Background: I would like to scan container images without running docker cli and docker socket on my agent.

This may be related to #1645 and #2179.

Current behavior

# print jf version
$ jf --version
jf version 2.51.1

# download image in oci format
$ skopeo copy --format oci docker://ubuntu:22.04 oci-archive:scan_target_oci.tar
Getting image source signatures
Copying blob aece8493d397 done
Copying config e4c5895818 done
Writing manifest to image destination
Storing signatures

# download image in v2s2 format
$ skopeo copy --format v2s2 docker://ubuntu:22.04 docker-archive:scan_target_v2s2.tar
Getting image source signatures
Copying blob aece8493d397 done
Copying config e4c5895818 done
Writing manifest to image destination
Storing signatures

# scan oci image
$ JFROG_CLI_LOG_LEVEL=DEBUG jf scan scan_target_oci.tar > scan_target_oci_out.txt 2>&1
$ echo $?
0

# scan v2s2 image
$ JFROG_CLI_LOG_LEVEL=DEBUG jf scan scan_target_v2s2.tar > scan_target_v2s2_out.txt 2>&1
$ echo $?
0

I censored our private domain with <**censored**>. Here is the log output:

scan_target_oci_out.txt
scan_target_v2s2_out.txt

Reproduction steps

See Current behavior

Expected behavior

First of all I expected the scan to work because the tar archieves are recognized as container images.
Then I expected the Failed to index tar file as container image to be an ERROR instead of an WARN.
Furthermore I expected the command to fail if such error occurs and exit with a non-zero exit code.

JFrog CLI version

jf version 2.51.1

Operating system type and version

Ubuntu 22.04.3 LTS

JFrog Artifactory version

{"version":"7.68.14","revision":"76814900"}

JFrog Xray version

{"xray_version":"3.85.5","xray_revision":"8ef6b2d"}

[rcarre]

Dear @cospeedster,
I have a similar backgroud I would like to scan container images without running docker cli mainly to avoid DinD in Gitlab pipelines environment.
I managed it thanks to buildah

buildah push --format docker my_image:tag docker-archive:my_image.tar
jf scan my_image.tar

However I get some warnings but scan vulnerability output is as expected

14:43:07 [🔵Info] JFrog Xray version is: 3.86.10
14:43:07 [🔵Info] [Thread 2] Indexing file: my_image.tar
14:44:05 [🔵Info] 2024/02/12 14:43:08 maxprocs: Leaving GOMAXPROCS=4: CPU quota undefined
2024-02-12T14:43:42.885Z [jfxia] [INFO ] [] [extractor:173                 ] [UnnamedContext                  ] Encountered release info file 'etc/lsb-release'
2024-02-12T14:43:45.918Z [jfxia] [INFO ] [] [archive_helper:61             ] [BackgroundContext               ] SPDX license IDs from licenses.json and exceptions.json were loaded successfully
2024-02-12T14:44:02.037Z [jfxia] [WARN ] [] [zip:25                        ] [TODOContext                     ] failed to extract zip: zone info file found instead of zip
2024-02-12T14:44:05.064Z [jfxia] [WARN ] [] [zip:25                        ] [TODOContext                     ] failed to extract zip: zone info file found instead of zip
2024-02-12T14:44:05.230Z [jfxia] [WARN ] [] [zip:25                        ] [TODOContext                     ] failed to extract zip: zone info file found instead of zip
2024-02-12T14:44:05.529Z [jfxia] [INFO ] [] [docker:114                    ] [UnnamedContext                  ] Finished indexing layers of docker /tmp/jfrog.cli.temp.-1
14:44:06 [🔵Info] Waiting for scan to complete on JFrog Xray...
💬The full scan results are available here: /tmp/jfrog.cli.temp.-1707749067-959317702

[cospeedster]

Hi @rcarre,
thank you for your contribution of a workaround!

For now I'm getting around this by using jf docker scan because I'm able to use Docker on my agent.

Anyway, I'd apreciate some support from JFrog here.

[rcarre]

I guess the reason why you do not get the expected code is because you did not check fail_build key in your default watch policies.
Here are some details

[cospeedster]

But does this not only take effect if you use build scan via jf rt build-scan to scan a published build?

In context of this issue I'd like to use jf scan or jf xr scan to scan locally.

I'll continue to follow your approach anyway. Thanks!

[guyshe-jfrog]

Related:
jfrog/jfrog-cli-security#30
Should add support for it docker scan with tar :)