project-zot / zot

zot - A scale-out production-ready vendor-neutral OCI-native container image/artifact registry (purely based on OCI Distribution Specification)

zot

zot: a production-ready vendor-neutral OCI image registry - images stored in OCI image format, distribution specification on-the-wire, that's it!

Documentation for zot is located at: https://zotregistry.dev

Code of conduct details are here.

License

zot's Issues

HEAD Request to manifest tag returns 500 when repo does not exist (should be 404)

When making HEAD request to nonexistent repository name, Zot produces the following error:

{
  "level": "error",
  "error": "repository: not found",
  "caller": "/go/src/github.com/anuvu/zot/pkg/api/routes.go:249",
  "time": "2020-02-12T21:41:02.455401195Z",
  "message": "unexpected error"
}

However, the status code on the HTTP response is 500, rather than 404

{
  "level": "info",
  "module": "http",
  "clientIP": "********",
  "method": "HEAD",
  "path": "/v2/pmengelbert/notexist/manifests/latest",
  "statusCode": 500,

The relevant switch/case is here:
https://github.com/anuvu/zot/blob/92241d17cba09ef17d591daec2081ae0ef695b49/pkg/api/routes.go#L245
It isn't checking for errors.RepoNotFound, and is defaulting to 500 response

Security Procedures

As a user and contributor, I want a document describing the project security response procedures and how to report a security issue.

Acceptance Criteria:

• Create a SECURITY.md (or asciidoc) in root of project.
• Content should include
  • How to report a vulnerability
  • What to include when reporting a security vulnerability
  • How to subscribe to reported vulnerabilities
  • How the project responds to security vulnerabilities
  • List of project members on the security response team
  • Policy on vulnerability disclosure (i.e., embargo period)
  • Process for assigning a CVE

SessionLogger includes unhelpful static `caller`

SessionLogger being a nested func means that all the logs include
"caller":"/root/go/src/github.com/anuvu/zot/pkg/log/log.go:113"
and it's always the same.

If there's a way to reorganize the code to get a useful Caller(), great, otherwise can we leave it out and make the logs a little easier to read?

Thanks!

Decide on Markdown or Asciidoc for project documentation.

As a user, I need a consistent documentation formatting standard.

Acceptance Criteria

• Choose one of:
  • Asciidoc
  • Markdown

This standard should be used for all documentation including root docs such as README, CONTRIBUTING, etc.

cli: add a client cli to interact with zot server

We could just follow the single binary model.

Zot extensions

Goal

Zot should provide an extension mechanism to implement additional features outside the OCI specification. Extensions provides a way to implement experimental/draft features to the OCI community and gain experience with these use cases. If and when these features are standardized, zot will promote the extensions to core feature set and can be the reference implementation of the specification.

All extensions are compiled in to the zot binary and can be selectively enabled/disabled using runtime configuration.

Extensions

Zot supports two types of extensions. Inline extensions which are called as requests are being processed by zot. Asynchronous extensions which are called after an event finished.

Inline Extension

Extension points that are called inline with a repository feature like push image, pull image and list, create, update, delete manifests and all operations. We will use the middleware pattern to register the extension points that will extend each of this feature and can react to these events inline as they are being processed by zot.

Async Extension

Async extensions are invoked in their own context in reaction to an event. For example CRUD operations on an image or a repository. There is no ordering guarantee for the extensions, all of them may be invoked in parallel.

Configuration

Each extension must be explicitly configured and only configured extensions are registered with runtime and invoked appropriately. Here is a sample configuration

{
  "extensions": [
    {"scan": { "scanInterval" : "10m" }},
    {"query": {"queryPort" : 6000}},
  ]
}

tweak contents of _catalog

If I create images called 'host:v1' and 'proj1/dest:v1', then curl of /v2/_catalog will show me 'host' and 'proj1'. I think it would be nice to give the full path of each of those.

clustering: zot scale-out cluster

We will want to support running a cluster of zot servers.

When a blob is uploaded, it should be distributed to all the nodes.

When fetching an image, the client should be able to fetch each
layer blob from a different server to load balance.

Root access for skopeo in Makefile

Hello guys,

Why are you using sudo for skopeo operations?
Example: https://github.com/project-zot/zot/blob/main/Makefile#L50

Public container image

Please publish a public container image on Quay/Docker Hub (or other) in order to use for OCI conformance purposes

golangci-lint error with go 1.13+

When building with go 1.13.5 the following error happens:

--- PASS: TestAPIs (0.03s)
PASS
coverage: 67.8% of statements
ok      github.com/anuvu/zot/pkg/storage        1.080s  coverage: 67.8% of statements
golangci-lint --version || curl -sfL https://install.goreleaser.com/github.com/golangci/golangci-lint.sh | sh -s v1.17.1
/bin/sh: 1: golangci-lint: not found
golangci/golangci-lint info checking GitHub for tag 'v1.17.1'
golangci/golangci-lint info found version: 1.17.1 for v1.17.1/linux/amd64
golangci/golangci-lint info installed ./bin/golangci-lint
golangci-lint  --config .bazel/golangcilint.yaml run --enable-all ./cmd/... ./pkg/...
pkg/log/log.go:1: /usr/local/go/src/path/match.go:200:15: DecodeRuneInString not declared by package utf8 (typecheck)
package log
pkg/storage/storage.go:1: /usr/local/go/src/path/filepath/match.go:215:15: DecodeRuneInString not declared by package utf8 (typecheck)
package storage
pkg/api/auth.go:1: /usr/local/go/src/fmt/scan.go:1200:16: DecodeRuneInString not declared by package utf8 (typecheck)
package api
pkg/cli/root.go:1: /usr/local/go/src/strings/strings.go:980:20: DecodeRuneInString not declared by package utf8 (typecheck)
package cli
cmd/zot/main.go:1: /usr/local/go/src/strconv/quote.go:405:12: ValidString not declared by package utf8 (typecheck)
package main
cmd/zot/main_test.go:1: /usr/local/go/src/encoding/json/fold.go:83:20: DecodeRune not declared by package utf8 (typecheck)
package main_test
pkg/api/controller_test.go:1: /home/zendril/go/pkg/mod/github.com/json-iterator/[email protected]/stream_str.go:275:19: DecodeRuneInString not declared by package utf8 (typecheck)
package api_test
pkg/cli/root_test.go:1: /usr/local/go/src/bytes/reader.go:98:18: DecodeRune not declared by package utf8 (typecheck)
package cli_test
pkg/compliance/v1_0_0/check_test.go:1: /usr/local/go/src/strconv/quote.go:405:12: ValidString not declared by package utf8 (typecheck)
package v1_0_0_test
pkg/storage/storage_test.go:1: /usr/local/go/src/regexp/regexp.go:967:22: DecodeRuneInString not declared by package utf8 (typecheck)
package storage_test
make: *** [Makefile:27: check] Error 1

Looks like it is related to golangci/golangci-lint#658 and is fixed.

Create project ROADMAP

As a project viewer, I would like to quickly understand the future plans for the project.

Acceptance Criteria:

• Create ROADMAP.md (or asciidoc) in root of project. List upcoming features and architectural changes including expected release milestones.
• Include relevant alignment to dependent projects or project dependencies in the ecosystem.
• Create matching milestones for immediate future work in project.
• Map roadmap features to Issues and associate to milestones or backlog priority
• Include or link to document describing release cadence.
• Link to ROADMAP.md from README.md

cli: add options to specify output format like json, plaintext, yml

cli: add command to fetch images affected by a CVE

add access control support

zot currently lacks access control support. A needed feature if a single instance needs to be shared across multiple tenants.

ci/cd: use oci dist-spec published conformance container

dist-spec conformance container is available - use this in our ci/cd pipeline so that we don't break conformance (ever).

jdolitsky  12:12 PM
Ok, we now have a public image for dist-spec conformance suite :tada:

ghcr.io/opencontainers/distribution-spec/conformance:<COMMIT|TAG>

Example:

docker run --rm \
  -v $(pwd)/results:/results \
  -w /results \
  -e OCI_ROOT_URL="https://r.myreg.io" \
  -e OCI_NAMESPACE="myorg/myrepo" \
  -e OCI_USERNAME="myuser" \
  -e OCI_PASSWORD="mypass" \
  -e OCI_TEST_PULL=1 \
  -e OCI_TEST_PUSH=1 \
  -e OCI_TEST_CONTENT_DISCOVERY=1 \
  -e OCI_TEST_CONTENT_MANAGEMENT=1 \
  -e OCI_HIDE_SKIPPED_WORKFLOWS=0 \
  -e OCI_DEBUG=0 \
  -e OCI_DELETE_MANIFEST_BEFORE_BLOBS=0 \
  ghcr.io/opencontainers/distribution-spec/conformance:db4cc68

cli: add a default config if not specified

Right now, we need to pass a config alias with each command. Instead we can make it optional and make user able to choose a config as default.

For example

$ zot images remote-zot

Instead of this we could have a default config and then the command will look like

$ zot images

cli: sort CVEs of an image by its severity

We can display the CVEs with highest priority on the top of the list.

Third-Party Dependency and License List

As a user, I want a list of all the project's direct software dependencies and their respective licenses.

Acceptance Criteria:

• Use a tool to automate collection of direct dependencies and their licenses. For example, the following tools do this:
  • https://github.com/google/go-licenses
  • https://github.com/go-enry/go-license-detector
• Publish list of third-party dependencies and licenses to THIRD-PARTY-LICENSES.md (or asciidoc).

A good example output is https://github.com/kubernetes/cloud-provider-aws/blob/master/THIRD-PARTY-LICENSES.

add LDAP authentication support

Currently, zot supports only mutual TLS and htpasswd authN. Would be useful to add LDAP support so that can hook up to Windows AD (for example)

Project Governance

As a project owner, manager or maintainer, I want to clearly communicate the governance model for this project.

Acceptance Criteria:

• Create GOVERNANCE.md (or asciidoc) document in root of repository
• Create OWNERS.md (or asciidoc) document in root of repository and optionally in sub directories to define ownership of different areas of the project.
• Link to GOVERNANCE.md (or asciidoc) from README

Add Dockerfile for running zot server

There is a Dockerfile in the repo, but it is only used for development purposes

You can add multiple zot configs with the same name

$ zot config -l
$ zot config add main https://test-url.com
$ zot config -l
main    https://test-url.com
$ zot config add main https://test-url.com
$ zot config -l
main    https://test-url.com
main    https://test-url.com

Fix:

$ ./bin/zot config -l
$ ./bin/zot config add main https://test-url.com
$ ./bin/zot config -l
main    https://test-url.com
$ ./bin/zot config add main https://test-url.com
Error: config: config name is used. see 'zot config -l'
Usage:
  zot config add <config-name> <url> [flags]

Flags:
  -h, --help   help for add

Useful variables:
  url           zot server URL
  showspinner   show spinner while loading data [true/false]
  verify-tls    verify TLS Certificate verification of the server [default: true]

logs: add an audit log for API calls

Keep a separate audit log to track only API actions (separate from verbose logs)

Label Taxonomy

As a project manager, maintainer, or contributor, I would like to quickly analyze existing issues and PRs by applying label filters to understand what work needs to be triaged, assigned, completed, etc. and to help me manage the backlog.

The goal is not to create every label we think we may need as this list can evolve.

Review and update label taxonomy to enable visibility of:

• clear priority of backlog
• triage needed on issues (more information, duplicate, etc.)
• type of issue (feature request, documentation, proposal, bug, security, etc.)
• area/ownership
• support of automated processes (requires-cla, cla-not-needed, test failure, etc.)
• contributor support (good-first-issue, need-help, etc.)
• issue lifecyle (active, frozen, rotten, stale) so we can auto close (or prevent close of) issues that have no activity - backlog maintenance

Acceptance Criteria

• Asciidoc documenting list of labels
• Labels created in GitHub
• Description of each label
• Who can assign each label (person or automated process)
• Which labels are requirements for the submission of a new issue (this can also be handled in a initial issue triage step).
• Document process for requesting and adding new labels.

Development Environment Setup Documentation

As a new contributor, I want instructions on how to setup a best practice development environment to work on and debug the project code and other assets.

Acceptance Criteria:

• Publish Development Environment Setup Instructions by either
  • Adding a section to CONTRIBUTING.md (or asciidoc)
  • Creating separate document in docs.

DELETE manifest MUST be allowed only when <reference> is a digest

@pmengelbert pointed out rightly that:

DELETE Manifest

Delete the manifest identified by name and reference. Note that a manifest can only be deleted by digest.

add token-based authentication

Currently, supports only "BASIC", need "BEARER token" support as well.
Also, so we don't clobber LDAP server if configured as authN backend.

Image deletion and garbage collection

zot needs to be "nicer" when deleting images meaning blobs referenced in the manifest must be deleted safely as well. Currently, we expose the APIs and leave it to the user to handle this logic.

This also leads to the garbage collection feature.

Project Website

As a potential user or contributor, I would like to read about the project, find documentation, and browse recent activity on a curated website.

Additional issues can be created and linked back to this parent issue.

Acceptance Criteria:

• Find hosting provider
• Register a DNS name
• Choose static site generator (i.e., hugo, jekyll, gitbook, etc.)
• Ensure the website has the following content areas
  • Project summary statement (single short statement that describes the project)
  • List of major features
  • Callout and link to latest release
  • Callout and link to latest media activity (webinars, community meetings, etc.)
  • Blog list
  • Getting Started callout
  • Contributing callout
  • Links to Project Handles (Twitter, Slack, GitHub)
  • Documentation
  • Community (calendar of events, support channels, etc.)
  • Presentations Link
• Automation to build and deploy the site
• Enable TLS using Let's Encrypt or equivalent (should be supported by hosting provider)
• Search Engine Optimization (SEO)
• Tweet and announce site launch

Establish Regular Community Meeting

As a contributor or user, I would like to engage with the community on a regular call to discuss features, architecture, support issues, and other community topics.

Acceptance Criteria:

• Schedule a video call at a time convenient for the majority of contributors and users.
• Ensure meeting can be recorded.
• Create an Asciidoc page in docs or use another document collaboration system (Google Docs) to capture planned agenda
• Assign an official scribe for the meeting to capture discussion and follow-up action items.
• Announce meeting
  • Twitter
  • Slack announcement channels in related communities
  • Sponsor social media accounts
• Put meeting schedule and list latest recordings/notes in README.md (or asciidoc)

chattr +i blobs, chattr -i blobs before deleting them

This is a defense-in-depth against layers being modified while on disk.

Remove test/data/htpasss

Remove it, have tests autogenerate one, and show in README to create one with htpasswd.

Other storage backends?

Right now it looks like Zot is a fantastic registry if I want to run it on a single machine. I'm particularly drawn to the LDAP support even though my preferred authentication only speaks LDAP by proxy. What I don't see is a way to run zot horizontally available. Is there no way to run Zot on top of a remote object store or similar option with nonlocal storage?

cli: rename "search" command to something else if there's a better word

cli: add command to fetch tags of an image which have fixed a CVE

single zot server instance should support multiple storage backends

At present a single zot instance have only one single storage i.e being specified in config file e.g

"storage":{
    "rootDirectory":"/tmp/zot"
  }

but now we want zot to be scalable in terms of storage and restriction is to be done using single zot server instance.

cli: add search command for repos/images

CLI needs search command to list repositories and the images inside them. We can utilize existing distribution spec APIs.

conformance: add a local Makefile target to run conformance tests

conformance tests run in the upstream ci/cd pipeline, but would be useful for developers to be able to run these locally.

cve: ImageListWithCVEFixed returning error on empty results

If there are no matching results for "ImageListWithCVEFixed" query, it is returning error: search: no fixed tag found

It should just return an empty list without any error message

Establish Communication Channels

As a user or contributor, I want a dedicated communication channel to work with project maintainers, other contributors, and users.

Acceptance Critera:

• Evaluate pros/cons of different communication mediums
• Create a channel for interactive chat
• Create a channel for announcements
  • Release announcements
  • General project news
  • Security announcements
• List communication channels in README.md
• Create automation for adding users to channels (for example, if Slack is used, we may need a slackin for membership invites)
• Create and publish acceptable use policy for communication channels.
• Notify users in README.md that comms channels are best effort support.

Possible Communication Channels

• IRC
• Slack
• Discord
• Email Distribution List / Newsgroup
• Other?

cli: given a layer hash, return a list of images that contain that layer

Currently, we support listing/searching images within a repo, but we have found it useful to also retrieve a list of images given a layer hash.

Submit preliminary OCI distribution-spec conformance results

Hello - please see these instructions for how to certify zot as OCI-conformant: https://github.com/opencontainers/oci-conformance/blob/master/instructions.md

As the distribution spec has not yet reached 1.0, please simply use "v1.0-pre" as the spec version number. For example, open a PR on opencontainers/oci-conformance containing the following files:

distribution-spec/v1.0-pre/zot/README.md
distribution-spec/v1.0-pre/zot/report.html
distribution-spec/v1.0-pre/zot/junit.xml
distribution-spec/v1.0-pre/zot/PRODUCT.yaml

Please reach out if you have any questions.

html/json reporting for compliance checks

As per discussion in [1], there is a requirement to generate a compliance check report in html or json.

zot uses goconvey [2] for driving unit tests and by extension, the compliance checks. goconvey has a reporting [3] package that could help with this.

References:
[1] https://groups.google.com/a/opencontainers.org/forum/m/#!topic/dev/JCpfBI-_woQ
[2] https://github.com/smartystreets/goconvey
[3] https://godoc.org/github.com/smartystreets/goconvey/convey/reporting

cli: add command to fetch CVE list for an image

incorrect list of fixed images given CVE-ID

Zot does not support squashfs image vulnerability scanning, when retrieving fixed images given particular CVE zot is returning squashfs images also, ideally squashfs images should not be in the list because zot doesn't support its scanning.

Code of Conduct

As a community member, I want to understand what the acceptable code of conduct is for participating in this project.

Acceptance Critera:

• Adopt a code of conduct that is compatible with CNCF Code of Conduct.
• Create and publish Code of Conduct in CODE_OF_CONDUCT.md (or asciidoc) at root of repository.
• Link to CODE_OF_CONDUCT.md (or asciidoc) from README.md

Bearer auth scope on endpoints with empty-string namespace should resemble "repository::<action>"

Currently when requesting the "/v2/" endpoint with bearer auth enabled, the Www-Authenticate header returns something like this:

Www-Authenticate: Bearer realm="https://<my_url>/auth/token",service="<my_url>",scope="repository:repo:pull"

This is due to the underlying library using a default value of "repo" for repository name when none is provided. This would cause issues, for example, if the registry literally had a repository named "repo".

Instead, the Www-Authenticate header should use a scope such as "repository::<action>":

Www-Authenticate: Bearer realm="https://<my_url>/auth/token",service="<my_url>",scope="repository::pull"

CONTRIBUTING.md (or asciidoc)

As a prospective contributor, I want documentation explaining the process and expectations for contributing to this project.

Acceptance Criteria:

• Create CONTRIBUTING.md (or asciidoc) in root of project.
• Documentation should include:
  • How to get started including how to sign a Contributor License Agreement
  • Pointers to a project architecture document and other relevant information needed to familiarize a new contributor with project internals.
  • Link to how to setup a development environment.
  • Instructions on setting up any required accounts
  • GitHub workflow
  • How to request review of Issues and PRs
  • Issue and PR management including Issue Triage

Don't assume that the reader of this document has any background knowledge of the project, acronyms, etc. This document should enable self-service startup for new contributors.

harden zot server for general deployments

1. API attacks
2. DoS attacks
3. Access control