* chore: use go1.23 in the build environment of zot container images
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
* chore: increase timeout in test/blackbox/restore_s3_blobs.bats
Looks like the message is actually there even if the test fails, maybe there is a timing issue.
https://github.com/project-zot/zot/actions/runs/11747889146/job/32730772641
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
---------
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
The Trivy library now supports multiple locations from where to download the DBs.
The zot code has been updated to properly call the updated library functions.
If at some point we would want to support multiple Trivy DBs in zot, we could look into it more.
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
There are 2 remaining exceptions that I am aware of:
1. The tests under test/blackbox/cve.bats
2. One of the cli tests checking the server attempts download of the databases
from the default url
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
* feat: add support for docker images
Issue #724
A new config section under "HTTP" called "Compat" is added which
currently takes a list of possible compatible legacy media-types.
https://github.com/opencontainers/image-spec/blob/main/media-types.md#compatibility-matrix
Only "docker2s2" (Docker Manifest V2 Schema V2) is currently supported.
Garbage collection also needs to be made aware of non-OCI compatible
layer types.
feat: add cve support for non-OCI compatible layer types
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
*
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
* test: add more docker compat tests
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
* feat: add additional validation checks for non-OCI images
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
* ci: make "full" images docker-compatible
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
---------
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
See #2744, there are 2 updates:
1. Silence the usage output in case of config verification errors
2. Wrap the error details in all of the zot configuration errors so they are propagated and shown in stdout for `zot verify`
We also need to keep logging those message to the zot logs file since the same logic is caled in the `zot serve` use case.
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
Exit early in case of all folders and known non-blob file names.
This avoids the logic for validating digests, and log message generation.
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
Looks like we didn't have many GC tests for retaining multiarch images.
I added more data to the existing image retention tests, besides the new GC tests.
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
cache.HasBlob() looks in both buckets: duplicates and original blobs
Because we want to check if the blob is in original bucket let's use
cache.GetBlob() because it's looking only in original bucket.
Signed-off-by: Eusebiu Petu <petu.eusebiu@gmail.com>
In case of delete by tag only the tag is removed, the manifest itself would continue to be accessible by digest.
In case of delete by digest the manifest would be completely removed (provided it is not used by an index or another reference).
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
chore: upgrade trivy to v0.55.2, also update the logic of waiting for zot to start in some jobs
Seems like there's an increate in the time zot requires to start before servicing requests.
From my GitHub observations it is better check using curl instead of relying on hardcoded 5s or 10s values.
The logic in .github/workflows/cluster.yaml seems to be old and out of date.
Even on main right now there is only 1 our of 3 zots actualy running.
The other 2 are actually erroring: Error: operation timeout: boltdb file is already in use, path '/tmp/zot/cache.db'
This is unrelated to this PR, I am seeing the same issue in the olders workflow runs still showing the logs
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
Fixes issue #2627
We get/put metadata in dynamodb and it appears there are limits enforced
by AWS S3 APIs.
https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_BatchGetItem.html
If you request more than 100 items, BatchGetItem returns a
ValidationException with the message "Too many items requested for the
BatchGetItem call."
Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
fix(authn): configurable hashing/encryption keys used to secure cookies
If they are not configured zot will generate a random hashing key at startup,
invalidating all cookies if zot is restarted. closes: #2526
Signed-off-by: Petu Eusebiu <peusebiu@cisco.com>
