Xray has a safety mechanism in place to ensure a "zip bomb" does not bring down the application. In some situations a legitimate file may cause the safety mechanism to trigger.
Zip files, and other archives such as tar.gz, with more than 200,000 files within it will trigger this error:
[xray-indexer-service.log] 2022-11-01T17:15:30.033Z [jfxid] [ERROR] [61d9004be7d4776e] [zip:24] [main] failed to check file /opt/jfrog/xray/var/work/indexer/artifacts/0[...]86/zip-bomb.zip, with err: too many entries in archive 2022-11-01T17:15:30.095Z [jfxid] [ERROR] [19d0c0a58128124b] [exchange_handler:662 ] [main ] Worker index id 1 failed to process message error: Index worker 1 failed to process message --> [...] --- at /go/src/jfrog.com/xray/internal/workers/index_worker.go:157 (IndexWorker.processMsg) --- Caused by: Index worker 1 failed to index artifact --- at /go/src/jfrog.com/xray/internal/workers/index_worker.go:198 (IndexWorker.IndexFile) --- Caused by: failed to extract file zip-bomb.zip (root path: default/builds/). --- at /go/src/jfrog.com/xray/indexer/indexer_core/archive_mgr.go:261 (ArchiveManager.deepArchiveScanWrapper) --- Caused by: Irrecoverable Error: too many entries in archive
The solution is to raise the safety mechanism's limit to allow Xray to scan the file. Update the xray system.yaml with these lines, they take effect after restarting Xray:
indexer: compress: # Max entries per archive # Default limit: 200,000 MaxEntities: 2000000 # Limit on how much bigger the file can be when unzipped # Ratio from: unzipped / zipped - Ex: 1 GB unzipped vs 1 MB zipped = 1000x # Default: 200 RationLimit: 2000
Please note that this safety mechanism is there for a good reason. You need to ensure the Xray host can handle unpacking these kinds of archive files. Ensure there are enough IOPS, CPU, and RAM resources on the host as mentioned in our System Requirements, and that there is enough disk space to fully unpack the archive.
You may also be interested in this KB with a related setting.