In order to verify signatures, users could upload their certificates and public keys using these routes:
-> for public keys:
/v2/_zot/ext/mgmt?resource=signatures&tool=cosign
-> for certificates:
/v2/_zot/ext/mgmt?resource=signatures&tool=notation&truststoreType=ca&truststoreName=name
Then the public keys will be stored under $rootdir/_cosign and the certificates will be stored under
$rootdir/_notation/truststore/x509/$truststoreType/$truststoreName.
Also, for notation case, the "truststores" field of $rootir/_notation/trustpolicy.json file will be
updated with a new entry "$truststoreType:$truststoreName".
Also based on the uploaded files, the information about the signatures validity will be updated
periodically.
Signed-off-by: Andreea-Lupu <andreealupu1470@yahoo.com>
- AuthzHandler has now been split in BaseAuthzHandler and DistSpecAuthzHandler
The former populates context with user specific data needed in most handlers, while
the latter executes access logic specific to distribution-spec handlers.
Signed-off-by: Alex Stan <alexandrustan96@yahoo.ro>
Also modify zli to retry in case of such errors,
assuming the trivyDB will eventually be downloaded by the scheduled task.
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
before syncing an image we first check if it's already present in our storage
to do that we get the manifest from remote and compare it with the local one
but in the case of syncing docker images, because the conversion to OCI format is done while
syncing, we get a docker manifest before conversion, so sync detects that local manifest and
remote one are different, so it starts syncing again.
to overcome this, convert remote docker manifests to OCI manifests and then compare.
Signed-off-by: Petu Eusebiu <peusebiu@cisco.com>
ci(workflow): show disk usage and free up disk space used by unneeded tooling
ci(tests): routes tests: do not copy large images if they are not used later
ci(trivy): update a test: download trivy.db to a temporary folder
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
Initial code was contributed by Bogdan BIVOLARU <104334+bogdanbiv@users.noreply.github.com>
Moved implementation from a separate db to repodb by Andrei Aaron <aaaron@luxoft.com>
Not done yet:
- run/test dynamodb implementation, only boltdb was tested
- add additional coverage for existing functionality
- add web-based APIs to toggle the stars/bookmarks on/off
Initially graphql mutation was discussed for the missing API but
we decided REST endpoints would be better suited for configuration
feat(userdb): complete functionality for userdb integration
- dynamodb rollback changes to user starred repos in case increasing the total star count fails
- dynamodb increment/decrement repostars in repometa when user stars/unstars a repo
- dynamodb check anonymous user permissions are working as intendend
- common test handle anonymous users
- RepoMeta2RepoSummary set IsStarred and IsBookmarked
feat(userdb): rest api calls for toggling stars/bookmarks on/off
test(userdb): blackbox tests
test(userdb): move preferences tests in a different file with specific build tags
feat(repodb): add is-starred and is-bookmarked fields to repo-meta
- removed duplicated logic for determining if a repo is starred/bookmarked
Signed-off-by: Laurentiu Niculae <niculae.laurentiu1@gmail.com>
Co-authored-by: Andrei Aaron <aaaron@luxoft.com>
The zap scanner started to check the csp header, which is causing a warning.
We also need to ignore the rule, as both settings are read by the scanner.
Per https://w3c.github.io/webappsec-csp/#example-7bb4ce67 we can have multiple
Content-Security-Policy headers, and the most restrictive policies apply.
This rule doesn't seem to be applied by zap.
Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
