sigstore/cosignПодписание кода и прозрачность для контейнеров и бинарных файлов
<p align="center">
<img style="max-width: 100%;width: 300px;" src="https://raw.githubusercontent.com/sigstore/community/main/artwork/cosign/horizontal/color/sigstore_cosign-horizontal-color.svg" alt="Cosign logo"/>
</p>
# cosign
Подписывание OCI-контейнеров (и других артефактов) с помощью [Sigstore](https://sigstore.dev/)!
[](https://goreportcard.com/report/github.com/sigstore/cosign)
[](https://github.com/sigstore/cosign/actions/workflows/e2e-tests.yml)
[](https://bestpractices.coreinfrastructure.org/projects/5715)
[](https://securityscorecards.dev/viewer/?uri=github.com/sigstore/cosign)
Cosign стремится сделать подписи **невидимой инфраструктурой**.
Cosign поддерживает:
* «Безключевое подписывание» с помощью публичного сертификационного центра Fulcio проекта Sigstore и журнала прозрачности Rekor (по умолчанию)
* Подписывание с использованием аппаратных средств и KMS
* Подписывание с помощью сгенерированной cosign зашифрованной пары закрытого/открытого ключей
* Подписывание, проверку и хранение контейнеров в OCI-реестре.
* Собственную PKI
## Информация
`Cosign` разрабатывается в рамках проекта [`sigstore`](https://sigstore.dev).
Мы также используем [канал в Slack](https://sigstore.slack.com)!
Нажмите [здесь](https://join.slack.com/t/sigstore/shared_invite/zt-47srvpyn6-j8Ek5hGBwKN32IjLw8BvYA), чтобы получить ссылку-приглашение.
## Установка
Для установки через Homebrew, Arch, Nix, GitHub Action и Kubernetes см. [документацию по установке](https://docs.sigstore.dev/cosign/system_config/installation/).
Для бинарных файлов Linux, macOS и Windows см. [ресурсы релизов на GitHub](https://github.com/sigstore/cosign/releases/latest).
:rotating_light: Если вы загружаете релизы cosign из нашего бакета GCS — пожалуйста, ознакомьтесь с дополнительной информацией в [уведомлении об устаревании](https://blog.sigstore.dev/cosign-releases-bucket-deprecation/) от 31 июля 2023 г. :rotating_light:
## Установка для разработчиков
Если у вас установлен Go 1.22+, вы можете настроить среду разработки:
```shell
$ git clone https://github.com/sigstore/cosign
$ cd cosign
$ go install ./cmd/cosign
$ $(go env GOPATH)/bin/cosign
```
## Участие в разработке
Если вы заинтересованы в участии в разработке `cosign`, пожалуйста, прочитайте [документацию по участию](https://github.com/sigstore/cosign/blob/main/CONTRIBUTING.md).
Будущая разработка Cosign будет сосредоточена на следующем крупном релизе, который будет основан на
[sigstore-go](https://github.com/sigstore/sigstore-go). Сопровождающие сосредоточатся на разработке функций в
sigstore-go. Вклад в sigstore-go, особенно в части собственных ключей и подписывания, приветствуется.
Пожалуйста, ознакомьтесь с [трекером задач](https://github.com/sigstore/sigstore-go/issues) в поисках подходящих первых задач.
Cosign 2.x — это стабильный релиз, который продолжит получать периодические обновления функций и исправления ошибок. PR,
небольшие по объёму и масштабу, с наибольшей вероятностью будут быстро рассмотрены.
PR, которые существенно изменяют или нарушают API, не будут приняты. PR, значительные по размеру, но не
вносящие критических изменений, могут быть приняты, но будут считаться менее приоритетными, чем PR в sigstore-go.
## Dockerfile
Вот как установить и использовать cosign внутри Dockerfile через образ ghcr.io/sigstore/cosign/cosign:
```shell
FROM ghcr.io/sigstore/cosign/cosign:v2.4.1 as cosign-bin
# Source: https://github.com/chainguard-images/images/tree/main/images/static
FROM cgr.dev/chainguard/static:latest
COPY --from=cosign-bin /ko-app/cosign /usr/local/bin/cosign
ENTRYPOINT [ "cosign" ]
```
## Быстрый старт
Здесь показано, как:
* подписать образ контейнера с помощью метода «keyless signing» на основе идентификации по умолчанию (см. [документацию для получения дополнительной информации](https://docs.sigstore.dev/cosign/signing/overview/))
* проверить образ контейнера
* изучить более широкие сценарии подписи и проверки keyless-блобов в [Sigstore Cosign Quickstart](https://docs.sigstore.dev/quickstart/quickstart-cosign/)
### Подписать контейнер и сохранить подпись в реестре
Обратите внимание, что всегда следует подписывать образы на основе их дайджеста (`@sha256:...`),
а не тега (`:latest`), потому что иначе вы можете подписать не то, что
намеревались!
```shell
cosign sign $IMAGE
Generating ephemeral keys...
Retrieving signed certificate...
Note that there may be personally identifiable information associated with this signed artifact.
This may include the email address associated with the account with which you authenticate.
This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later.
By typing 'y', you attest that you grant (or have permission to grant) and agree to have this information stored permanently in transparency logs.
Are you sure you would like to continue? [y/N] y
Your browser will now be opened to:
https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&code_challenge=OrXitVKUZm2lEWHVt1oQWR4HZvn0rSlKhLcltglYxCY&code_challenge_method=S256&nonce=2KvOWeTFxYfxyzHtssvlIXmY6Jk&redirect_uri=http%3A%2F%2Flocalhost%3A57102%2Fauth%2Fcallback&response_type=code&scope=openid+email&state=2KvOWfbQJ1caqScgjwibzK2qJmb
Successfully verified SCT...
tlog entry created with index: 12086900
Pushing signature to: $IMAGE
```
Cosign предложит вам пройти аутентификацию через OIDC, где вы войдёте, используя свой адрес электронной почты.
Под капотом cosign запросит сертификат для подписи кода у центра сертификации Fulcio.
Субъект сертификата будет соответствовать адресу электронной почты, с которым вы вошли.
Затем Cosign сохранит подпись и сертификат в журнале прозрачности Rekor и загрузит подпись в реестр OCI вместе с образом, который вы подписываете.
### Проверка контейнера
Чтобы проверить образ, вам нужно передать ожидаемый субъект сертификата и издателя сертификата через флаги `--certificate-identity` и `--certificate-oidc-issuer`:
```
cosign verify $IMAGE --certificate-identity=$IDENTITY --certificate-oidc-issuer=$OIDC_ISSUER
```
Вы также можете передать регулярное выражение для флагов идентификатора сертификата и издателя: `--certificate-identity-regexp` и `--certificate-oidc-issuer-regexp`.
### Проверка контейнера по открытому ключу
Эта команда возвращает `0`, если для образа найдена *хотя бы одна* подпись в формате `cosign`,
соответствующая открытому ключу.
Подробности использования и предостережения относительно других форматов подписей см. ниже.
Все допустимые полезные нагрузки выводятся в stdout в формате json.
Обратите внимание, что эти подписанные полезные нагрузки включают дайджест образа контейнера, что позволяет
убедиться, что эти «отсоединённые» подписи относятся к правильному образу.
```shell
$ cosign verify --key cosign.pub $IMAGE_URI:1h
The following checks were performed on these signatures:
- The cosign claims were validated
- The signatures were verified against the specified public key
{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"sha256:87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8"},"Type":"cosign container image signature"},"Optional":null}
```
### Проверка контейнера в изолированной среде
**Примечание:** Этот раздел устарел.
**Примечание:** Большинство рабочих процессов проверки требуют периодического запроса сервисных ключей из репозитория TUF.
Для изолированной проверки подписей с использованием экземпляра public-good вам потребуется получить
[доверенный корень](https://github.com/sigstore/root-signing/blob/main/targets/trusted_root.json) из производственного
репозитория TUF. Содержимое этого файла будет меняться без уведомления. Не используя TUF, вам придётся
создать собственный механизм для поддержания актуальности вашей изолированной копии этого файла.
Cosign может выполнять полностью офлайн-проверку путём проверки [bundle](https://github.com/sigstore/cosign/blob/main/specs/SIGNATURE_SPEC.md#properties), который обычно распространяется как аннотация в манифесте образа.
Пока эта аннотация присутствует, офлайн-проверка может быть выполнена.
Эта аннотация bundle всегда включается по умолчанию для безключевой подписи, поэтому стандартная функциональность `cosign sign` будет включать все материалы, необходимые для офлайн-проверки.
Чтобы проверить образ в изолированной среде, образ и подписи должны быть доступны локально в файловой системе.
Образ можно сохранить локально с помощью `cosign save` (обратите внимание, этот шаг должен выполняться при наличии сетевого подключения):
```
cosign initialize # This will pull in the latest TUF root
cosign save $IMAGE_NAME --dir ./path/to/dir
```
Теперь в изолированной среде этот локальный образ можно проверить:
```shell
cosign verify \
--certificate-identity $CERT_IDENTITY \
--certificate-oidc-issuer $CERT_OIDC_ISSUER \
--offline=true \
--new-bundle-format=false \ # for artifacts signed without the new protobuf bundle format
--trusted-root ~/.sigstore/root/tuf-repo-cdn.sigstore.dev/targets/trusted_root.json \ # default location of trusted root
--local-image ./path/to/dir
```
Вам нужно будет передать ожидаемые значения для `$CERT_IDENTITY` и `$CERT_OIDC_ISSUER`, чтобы правильно проверить этот образ.
Если вы подписывали с помощью пары ключей, та же команда сработает, при условии, что материал открытого ключа присутствует локально:
```
cosign verify --key cosign.pub --offline --local-image ./path/to/dir
```
### Подписывание и проверка blob-объектов на основе идентичности
Используйте безключевое подписывание blob-объектов (`cosign sign-blob` без `--key`) и проверяйте по ожидаемой идентичности подписывающего:
```shell
$ cosign sign-blob artifact --bundle artifact.sigstore.json --yes
$ cosign verify-blob artifact \
--bundle artifact.sigstore.json \
--certificate-identity "https://github.com/ORG/REPO/.github/workflows/release.yml@refs/heads/main" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com"
```
### Устранение неполадок
Если вы столкнулись с проблемами при работе с Cosign, сначала убедитесь, что вы используете последнюю версию: проект Cosign активно поддерживает как самый последний выпуск, так и последний выпуск серии v2.
#### Распространённые проблемы и способы их решения
1. Проверка завершается ошибкой `failed to verify timestamps: threshold not met for verified log entry integrated timestamps: 0 < 1`: возможно, вы проверяете подпись, требующую поддержки временных меток RFC3161
* Обновитесь до последней версии Cosign или
* В Cosign 2.6.x используйте `--use-signed-timestamps`
1. Проверка завершается ошибкой `no signatures found`: возможно, вы проверяете подпись образа, требующую поддержки журнала прозрачности Rekor v2
* Обновитесь до последней версии Cosign
1. Подписывание завершается ошибкой с HTTP-ошибками: подписывание с помощью Cosign зависит от нескольких сервисов Sigstore. Повторная попытка при сбое может быть полезным обходным решением, если какой-либо из этих сервисов недоступен -- также приветствуется создание issue для конкретных сбоев
#### Моя проблема в чём-то другом
Пожалуйста, откройте [issue](https://github.com/sigstore/cosign/issues/new/choose) или задайте вопрос в [slack-канале](#info).
## Работа с другими артефактами
Реестры OCI полезны для хранения не только образов контейнеров!
`Cosign` также включает некоторые утилиты для публикации универсальных артефактов, включая бинарные файлы, скрипты и файлы конфигурации, с использованием протокола OCI.
В этом разделе показано, как использовать их для простой в использовании, обратно совместимой системы распространения артефактов, которая хорошо интегрируется с остальной частью Sigstore.
Дополнительную информацию см. в [документации](https://docs.sigstore.dev/cosign/signing/other_types/).
### Blobs
Вы можете опубликовать артефакт с помощью `cosign upload blob`:
```shell
$ echo "my first artifact" > artifact
$ BLOB_SUM=$(shasum -a 256 artifact | cut -d' ' -f 1) && echo "$BLOB_SUM"
c69d72c98b55258f9026f984e4656f0e9fd3ef024ea3fac1d7e5c7e6249f1626
$ BLOB_NAME=my-artifact-$(uuidgen | head -c 8 | tr 'A-Z' 'a-z')
$ BLOB_URI=ttl.sh/$BLOB_NAME:1h
$ BLOB_URI_DIGEST=$(cosign upload blob -f artifact $BLOB_URI) && echo "$BLOB_URI_DIGEST"
Uploading file from [artifact] to [ttl.sh/my-artifact-f42c22e0:5m] with media type [text/plain]
File [artifact] is available directly at [ttl.sh/v2/my-artifact-f42c22e0/blobs/sha256:c69d72c98b55258f9026f984e4656f0e9fd3ef024ea3fac1d7e5c7e6249f1626]
Uploaded image to:
ttl.sh/my-artifact-f42c22e0@sha256:790d47850411e902aabebc3a684eeb78fcae853d4dd6e1cc554d70db7f05f99f
```
Ваши пользователи могут скачать его по «прямому» URL-адресу с помощью стандартных инструментов, таких как curl или wget:
```shell
$ curl -L ttl.sh/v2/$BLOB_NAME/blobs/sha256:$BLOB_SUM > artifact-fetched
```
Дайджест встроен прямо в URL, так что они могут проверить и его:
```shell
$ cat artifact-fetched | shasum -a 256
c69d72c98b55258f9026f984e4656f0e9fd3ef024ea3fac1d7e5c7e6249f1626 -
```
Вы можете подписать его обычной командой `cosign sign` и флагами:
```shell
$ cosign sign --key cosign.key $BLOB_URI_DIGEST
Enter password for private key:
Pushing signature to: ttl.sh/my-artifact-f42c22e0
```
Как обычно, обязательно ссылайтесь на любые образы, которые вы подписываете, по их дайджесту, чтобы убедиться, что вы не подписываете не то!
#### Tekton Bundles
Пакеты [Tekton](https://tekton.dev) можно загружать и управлять ими в OCI-реестре.
Спецификация находится [здесь](https://tekton.dev/docs/pipelines/tekton-bundle-contracts/).
Это означает, что их также можно подписывать и проверять с помощью `cosign`.
В настоящее время пакеты Tekton можно загружать с помощью [tkn cli](https://github.com/tektoncd/cli), но мы можем добавить эту поддержку в
`cosign` в будущем.
```shell
$ tkn bundle push us.gcr.io/dlorenc-vmtest2/pipeline:latest -f task-output-image.yaml
Creating Tekton Bundle:
- Added TaskRun: to image
Pushed Tekton Bundle to us.gcr.io/dlorenc-vmtest2/pipeline@sha256:124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155
$ cosign sign --key cosign.key us.gcr.io/dlorenc-vmtest2/pipeline@sha256:124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155
Enter password for private key:
tlog entry created with index: 5086
Pushing signature to: us.gcr.io/dlorenc-vmtest2/demo:sha256-124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155.sig
```
#### WASM
Модули Web Assembly также можно хранить в OCI-реестре, используя эту [спецификацию](https://github.com/solo-io/wasm/tree/master/spec).
Cosign может загружать их с помощью команды `cosign wasm upload`:
```shell
$ cosign upload wasm -f hello.wasm us.gcr.io/dlorenc-vmtest2/wasm
$ cosign sign --key cosign.key us.gcr.io/dlorenc-vmtest2/wasm@sha256:9e7a511fb3130ee4641baf1adc0400bed674d4afc3f1b81bb581c3c8f613f812
Enter password for private key:
tlog entry created with index: 5198
Pushing signature to: us.gcr.io/dlorenc-vmtest2/wasm:sha256-9e7a511fb3130ee4641baf1adc0400bed674d4afc3f1b81bb581c3c8f613f812.sig
```
#### eBPF
Модули [eBPF](https://ebpf.io) также можно хранить в OCI-реестре, используя эту [спецификацию](https://github.com/solo-io/bumblebee/tree/main/spec).
Образ ниже был собран с помощью инструмента `bee`. Дополнительную информацию можно найти [здесь](https://github.com/solo-io/bumblebee/)
Затем Cosign может подписывать эти образы так же, как и любые другие OCI-образы.
```shell
$ bee build ./examples/tcpconnect/tcpconnect.c localhost:5000/tcpconnect:test
$ bee push localhost:5000/tcpconnect:test
$ cosign sign --key cosign.key localhost:5000/tcpconnect@sha256:7a91c50d922925f152fec96ed1d84b7bc6b2079c169d68826f6cf307f22d40e6
Enter password for private key:
Pushing signature to: localhost:5000/tcpconnect
$ cosign verify --key cosign.pub localhost:5000/tcpconnect:test
Verification for localhost:5000/tcpconnect:test --
The following checks were performed on each of these signatures:
- The cosign claims were validated
- The signatures were verified against the specified public key
[{"critical":{"identity":{"docker-reference":"localhost:5000/tcpconnect"},"image":{"docker-manifest-digest":"sha256:7a91c50d922925f152fec96ed1d84b7bc6b2079c169d68826f6cf307f22d40e6"},"type":"cosign container image signature"},"optional":null}]
```
#### Аттестации in-toto
Cosign также имеет встроенную поддержку аттестаций [in-toto](https://in-toto.io).
Спецификация для них определена [здесь](https://github.com/in-toto/attestation).
Вы можете создать и подписать одну из локального файла-предиката, используя следующие команды:
```shell
$ cosign attest --predicate <file> --key cosign.key $IMAGE_URI_DIGEST
```
Поддерживаются все стандартные системы управления ключами.
Полезные нагрузки подписываются с использованием спецификации подписи DSSE, определённой [здесь](https://github.com/secure-systems-lab/dsse).
Для проверки:
```shell
$ cosign verify-attestation --key cosign.pub $IMAGE_URI
```
## Подробное использование
См. [документацию по использованию](https://docs.sigstore.dev/cosign/signing/overview/) для получения дополнительной информации.
## Аппаратные токены
См. [документацию по аппаратным токенам](https://docs.sigstore.dev/cosign/key_management/hardware-based-tokens/) для получения информации о том, как использовать `cosign` с аппаратным обеспечением.
## Поддержка реестров
`cosign` использует [go-containerregistry](https://github.com/google/go-containerregistry) для взаимодействия с реестрами, что обеспечивает в целом отличную совместимость, но некоторые реестры могут иметь особенности.
На сегодняшний день `cosign` протестирован и работает со следующими реестрами:
* AWS Elastic Container Registry
* GCP's Artifact Registry and Container Registry
* Docker Hub
* Azure Container Registry
* JFrog Artifactory Container Registry
* The CNCF distribution/distribution Registry
* GitLab Container Registry
* GitHub Container Registry
* The CNCF Harbor Registry
* Digital Ocean Container Registry
* Sonatype Nexus Container Registry
* Alibaba Cloud Container Registry
* Red Hat Quay Container Registry 3.6+ / Red Hat quay.io
* Elastic Container Registry
* IBM Cloud Container Registry
* Cloudsmith Container Registry
* The CNCF zot Registry
* OVHcloud Managed Private Registry
Мы стремимся к широкой поддержке реестров. Чтобы `sign` образы в реестрах, которые ещё не полностью поддерживают [OCI media types](https://github.com/sigstore/cosign/blob/main/specs/SIGNATURE_SPEC.md), может потребоваться использовать `COSIGN_DOCKER_MEDIA_TYPES` для переключения на устаревшие эквиваленты. Например:
```shell
COSIGN_DOCKER_MEDIA_TYPES=1 cosign sign --key cosign.key legacy-registry.example.com/my/image@$DIGEST
```
Пожалуйста, помогите протестировать и сообщить об ошибках, если вы обнаружите проблемы!
Инструкции можно найти в [tracking issue](https://github.com/sigstore/cosign/issues/40).
## Ограничения
### Намеренно отсутствующие функции
`cosign` генерирует только ключи ECDSA-P256 и использует хеши SHA256 как для эфемерной безключевой подписи, так и для подписи управляемым ключом.
Ключи хранятся в формате PKCS8 с кодировкой PEM.
Однако вы можете использовать `cosign` для хранения и извлечения подписей в любом формате, с любым алгоритмом.
### То, что, вероятно, следует изменить
#### Форматы полезной нагрузки
`cosign` поддерживает только формат [simple signing](https://www.redhat.com/en/blog/container-image-signing) от Red Hat для полезных нагрузок.
Он выглядит так:
```json
{
"critical": {
"identity": {
"docker-reference": "testing/manifest"
},
"image": {
"Docker-manifest-digest": "sha256:20be...fe55"
},
"type": "cosign container image signature"
},
"optional": {
"creator": "Bob the Builder",
"timestamp": 1458239713
}
}
```
**Примечание:** Это можно сгенерировать для ссылки на образ с помощью `cosign generate $IMAGE_URI_DIGEST`.
Я готов переключить этот формат на что-то другое, если это имеет смысл.
См. https://github.com/notaryproject/notation/issues/40 для одного из вариантов.
#### Детали реестра
Подписи `cosign` хранятся как отдельные объекты в OCI-реестре, со лишь слабой
ссылкой обратно на объект, который они «подписывают».
Это означает, что эта связь непрозрачна для реестра, и подписи *не будут* удалены
или собраны сборщиком мусора при удалении образа.
Аналогично, они **могут** легко копироваться из одной среды в другую, но это не
происходит автоматически.
Несколько подписей хранятся в списке, что, к сожалению, сегодня является состоянием гонки.
Чтобы добавить подпись, клиенты организуют операцию «чтение-добавление-запись», поэтому при конфликте
победит последняя запись.
##### Указание реестра
По умолчанию `cosign` будет хранить подписи в том же репозитории, что и образ, который он подписывает.
Чтобы указать другой репозиторий для подписей, можно задать переменную окружения `COSIGN_REPOSITORY`.
Это заменит репозиторий в предоставленном образе следующим образом:
```shell
$ export COSIGN_REPOSITORY=gcr.io/my-new-repo
$ cosign sign --key cosign.key $IMAGE_URI_DIGEST
```
Таким образом, подпись для `gcr.io/dlorenc-vmtest2/demo` будет храниться в `gcr.io/my-new-repo/demo:sha256-DIGEST.sig`.
Примечание: разные реестры могут ожидать разные форматы для «репозитория».
* Чтобы использовать [GCR](https://cloud.google.com/container-registry), достаточно имени реестра
вида `gcr.io/$REPO`, как в примере выше.
* Чтобы использовать [Artifact Registry](https://cloud.google.com/artifact-registry),
укажите полное имя образа, например
`$LOCATION-docker.pkg.dev/$PROJECT/$REPO/$STORAGE_IMAGE`, а не просто
репозиторий. Например,
```shell
$ export COSIGN_REPOSITORY=us-docker.pkg.dev/my-new-repo/demo
$ cosign sign --key cosign.key $IMAGE_URI_DIGEST
```
где `sha256-DIGEST` будет соответствовать дайджесту для
`gcr.io/dlorenc-vmtest2/demo`. Указание только репозитория, например
`$LOCATION-docker.pkg.dev/$PROJECT/$REPO`, не будет работать в Artifact Registry.
## Спецификация подписи
`cosign` вдохновлён такими инструментами, как [minisign](https://jedisct1.github.io/minisign/) и
[signify](https://www.openbsd.org/papers/bsdcan-signify.html).
Сгенерированные закрытые ключи хранятся в формате PEM.
Ключи шифруются паролем с использованием scrypt в качестве KDF и nacl/secretbox для шифрования.
Они имеют PEM-заголовок `ENCRYPTED SIGSTORE PRIVATE KEY`:
```shell
-----BEGIN ENCRYPTED SIGSTORE PRIVATE KEY-----
...
-----END ENCRYPTED SIGSTORE PRIVATE KEY-----
```
Публичные ключи хранятся на диске в стандартном формате PKIX с PEM-кодированием и заголовком `PUBLIC KEY`.
```
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAELigCnlLNKgOglRTx1D7JhI7eRw99
QolE9Jo4QUxnbMy5nUuBL+UZF9qqfm/Dg1BNeHRThHzWh2ki9vAEgWEDOw==
-----END PUBLIC KEY-----
```
## Спецификация хранилища
`cosign` хранит подписи в OCI-реестре и использует соглашение об именовании (тег на основе sha256 того, что мы подписываем) для поиска индекса подписи.
<p align="center">
<img src="https://raw.githubusercontent.com/sigstore/cosign/HEAD/images/signatures.dot.svg" />
</p>
---
[Read more](https://github.com/sigstore/cosign)