## المساهمة

إذا كنت مهتمًا بالمساهمة في `cosign`، فيرجى قراءة [وثائق المساهمة](https://github.com/sigstore/cosign/blob/HEAD/CONTRIBUTING.md).

سيركز التطوير المستقبلي لـ Cosign على الإصدار الرئيسي القادم الذي سيعتمد على
[sigstore-go](https://github.com/sigstore/sigstore-go). سيركز المشرفون على تطوير الميزات داخل
sigstore-go. المساهمات في sigstore-go، خاصة فيما يتعلق بالمفاتيح التي توفرها بنفسك (bring-your-own keys) والتوقيع، محل تقدير.
يرجى الاطلاع على [متتبع المشكلات](https://github.com/sigstore/sigstore-go/issues) للحصول على قضايا أولى جيدة.

Cosign 2.x هو إصدار مستقر وسيستمر في تلقي تحديثات ميزات دورية وإصلاحات للأخطاء. طلبات السحب (PRs)
صغيرة النطاق والحجم هي الأكثر احتمالًا للحصول على مراجعة سريعة.

لن يتم قبول طلبات السحب التي تعدل أو تكسر API بشكل كبير. قد يتم قبول طلبات السحب ذات الحجم الكبير التي لا تُحدث تغييرات جذرية، لكنها ستُعتبر ذات أولوية أقل من طلبات السحب في 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/static
FROM cgr.dev/chainguard/static:latest
COPY --from=cosign-bin /ko-app/cosign /usr/local/bin/cosign
ENTRYPOINT [ "cosign" ]

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.

سيطالبك Cosign بالمصادقة عبر OIDC، حيث ستسجّل الدخول باستخدام بريدك الإلكتروني.
في الخلفية، سيطلب cosign شهادة توقيع تعليمات برمجية من سلطة الشهادات Fulcio.
سيتطابق موضوع الشهادة مع البريد الإلكتروني الذي سجّلت الدخول به.
بعد ذلك، سيخزّن cosign التوقيع والشهادة في سجل Rekor للشفافية، ويرفع التوقيع إلى سجل OCI بجانب الصورة التي توقّعها.


### التحقق من حاوية

للتحقق من الصورة، ستحتاج إلى تمرير هوية الشهادة المتوقعة ومُصدِر الشهادة عبر العلامتين `--certificate-identity` و `--certificate-oidc-issuer`:```
cosign verify $IMAGE --certificate-identity=$IDENTITY --certificate-oidc-issuer=$OIDC_ISSUER

### التحقق من حاوية في بيئة معزولة عن الشبكة

**ملاحظة:** هذا القسم غير محدّث.

**ملاحظة:** تتطلب معظم سير عمل التحقق طلب مفاتيح خدمة بشكل دوري من مستودع TUF.
للتحقق المعزول عن الشبكة من التوقيعات باستخدام المثيل العام، ستحتاج إلى استرجاع ملف
[trusted root](https://github.com/sigstore/root-signing/blob/main/targets/trusted_root.json) من مستودع
TUF للإنتاج. ستتغير محتويات هذا الملف دون إشعار. بعدم استخدام TUF، ستحتاج
إلى بناء آليتك الخاصة للحفاظ على تحديث نسختك المعزولة عن الشبكة من هذا الملف.

يمكن لـ Cosign إجراء تحقق غير متصل بالإنترنت تمامًا عن طريق التحقق من [bundle](https://github.com/sigstore/cosign/blob/HEAD/specs/SIGNATURE_SPEC.md#properties) والذي يتم توزيعه عادةً كتعليق توضيحي على manifest الصورة.
طالما أن هذا التعليق التوضيحي موجود، يمكن إجراء التحقق غير المتصل.
يتم دائمًا تضمين تعليق الحزمة هذا افتراضيًا للتوقيع بدون مفتاح، لذا فإن وظيفة `cosign sign` الافتراضية ستتضمن جميع المواد اللازمة للتحقق غير المتصل.

للتحقق من صورة في بيئة معزولة عن الشبكة، يجب أن تكون الصورة والتوقيعات متاحة محليًا على نظام الملفات.

يمكن حفظ صورة محليًا باستخدام `cosign save` (لاحظ، يجب تنفيذ هذه الخطوة مع اتصال بالشبكة):```
cosign initialize # This will pull in the latest TUF root
cosign save $IMAGE_NAME --dir ./path/to/dir

ستحتاج إلى تمرير قيم متوقعة لكل من `$CERT_IDENTITY` و`$CERT_OIDC_ISSUER` للتحقق من هذه الصورة بشكل صحيح.
إذا قمت بالتوقيع باستخدام زوج مفاتيح، فسيعمل نفس الأمر، بافتراض توفر مادة المفتاح العام محليًا:```
cosign verify --key cosign.pub --offline --local-image ./path/to/dir

### استكشاف الأخطاء وإصلاحها

إذا واجهت مشكلات مع 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 متعددة. قد تكون إعادة المحاولة عند الفشل حلاً بديلاً مفيدًا إذا فشلت أي من هذه الخدمات — كما أن فتح مشكلات (issues) للإخفاقات المحددة محل تقدير

#### مشكلتي شيء آخر

يرجى فتح [مشكلة](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

الخلاصة مدمجة مباشرة في الرابط، حتى يمكنهم التحقق منها أيضًا:```shell
$ cat artifact-fetched | shasum -a 256
c69d72c98b55258f9026f984e4656f0e9fd3ef024ea3fac1d7e5c7e6249f1626  -

كالعادة، تأكد من الإشارة إلى أي صور تقوم بتوقيعها من خلال digest الخاص بها للتأكد من أنك لا توقّع الشيء الخطأ!

#### حزم Tekton

يمكن تحميل حزم [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

#### 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}]

جميع أنظمة إدارة المفاتيح القياسية مدعومة.
يتم توقيع الحمولات باستخدام مواصفة توقيع DSSE، المعرفة [هنا](https://github.com/secure-systems-lab/dsse).

للتحقق:```shell
$ cosign verify-attestation --key cosign.pub $IMAGE_URI

يرجى المساعدة في الاختبار والإبلاغ عن الأخطاء إذا رأيت مشكلات!
يمكن العثور على التعليمات في [قضية التتبع](https://github.com/sigstore/cosign/issues/40).

## تحذيرات

### ميزات مفقودة عمدًا

يولّد `cosign` مفاتيح ECDSA-P256 فقط ويستخدم تجزئات SHA256، لكل من التوقيع غير المفتاحي المؤقت (keyless signing) والتوقيع بالمفاتيح المُدارة.
تُخزَّن المفاتيح بصيغة PKCS8 بترميز PEM.
ومع ذلك، يمكنك استخدام `cosign` لتخزين واسترجاع التوقيعات بأي صيغة، ومن أي خوارزمية.

### أشياء ينبغي أن تتغير على الأرجح

#### صيغ الحمولة (Payload)

يدعم `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
    }
}

إذًا سيتم تخزين التوقيع الخاص بـ `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

تُخزَّن المفاتيح العامة على القرص بتنسيق PKIX القياسي المُرمَّز بـ PEM مع ترويسة `PUBLIC KEY`.```
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAELigCnlLNKgOglRTx1D7JhI7eRw99
QolE9Jo4QUxnbMy5nUuBL+UZF9qqfm/Dg1BNeHRThHzWh2ki9vAEgWEDOw==
-----END PUBLIC KEY-----

الآن قم بتوقيعه! باستخدام `cosign` بالطبع:```shell
$ cosign sign --key cosign.key us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifact@sha256:551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef
Enter password for private key:
Pushing signature to: us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifact:sha256-551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef.sig

## الأسئلة الشائعة

### لماذا لا نستخدم Notary v2

من الصعب الإجابة على هذا بإيجاز.
يحتوي هذا المنشور على بعض المقارنات:

[Notary V2 و Cosign](https://medium.com/@dlorenc/notary-v2-and-cosign-b816658f044d)

إذا وجدت منشورات مقارنة أخرى، فيرجى إرسال طلب سحب (PR) هنا وسنقوم بربطها جميعًا.

### لماذا لا نستخدم توقيع containers/image

توقيع `containers/image` قريب من `cosign`، ونعيد استخدام تنسيقات الحمولة.
يختلف `cosign` في أنه يوقّع بمفاتيح ECDSA-P256 بدلاً من PGP، ويخزّن
التوقيعات في السجل (registry).

### لماذا لا نستخدم TUF؟

أعتقد أن هذه الأداة مكمّلة لـ TUF، ويمكن استخدامهما معًا.
لم أجرب ذلك بعد، لكن أعتقد أنه يمكننا أيضًا إعادة استخدام سجل لتخزين TUF.

## متطلبات التصميم

* لا خدمات خارجية لتخزين التوقيعات أو الاستعلام عنها أو استرجاعها
* نهدف إلى تحقيق أكبر قدر ممكن من دعم السجلات
* يجب أن يعمل كل شيء عبر واجهة برمجة تطبيقات السجل (Registry API)
* يجب ألا تكون PGP مطلوبة على الإطلاق.
* يجب أن يكون المستخدمون قادرين على العثور على جميع التوقيعات لصورة معينة
* يمكن للموقّعين توقيع صورة بعد الدفع (push)
* يمكن لكيانات متعددة توقيع صورة
* توقيع صورة لا يغيّر الصورة
* تنفيذ نقي بلغة Go

## أفكار مستقبلية

### تغييرات على واجهة برمجة تطبيقات السجل

إن اصطلاح التسمية وأنماط التحديث من نوع قراءة-تعديل-كتابة التي نستخدمها لتخزين الأشياء في
سجل هي، دعنا نقول، "ملتوية" بعض الشيء.
أعتقد أنها الخيار الحقيقي الأفضل (الوحيد) المتاح اليوم، لكن إذا تغيّرت واجهة برمجة تطبيقات السجل
يمكننا تحسين هذه الأمور.

### أنواع أخرى

يمكن لـ `cosign` توقيع أي شيء في سجل.
توضح هذه الأمثلة توقيع صورة واحدة، لكن يمكنك أيضًا توقيع `Index` متعدد المنصات،
أو أي نوع آخر من القطع الأثرية.
يتضمن ذلك Helm Charts و Tekton Pipelines وأي شيء آخر يستخدم حاليًا سجلات OCI
للتوزيع.

هذا يعني أيضًا أنه يمكن تحميل أنواع جديدة من القطع الأثرية إلى سجل وتوقيعها.
من الأنواع المثيرة للاهتمام التي يمكن تخزينها وتوقيعها مستودعات TUF.
لم أجرب ذلك بعد، لكنني متأكد إلى حد ما من أنه يمكن تنفيذ TUF فوق هذا.

### توقيع العلامات (Tag Signing)

توقيعات `cosign` تحمي ملخصات (digests) الكائنات المخزنة في سجل.
يمكن استخدام دعم `annotations` الاختياري (عبر العلم `-a` مع `cosign sign`) لإضافة بيانات
إضافية إلى الحمولة التي يتم توقيعها وحمايتها بالتوقيع.
إحدى حالات الاستخدام لهذا قد تكون توقيع تعيين علامة->ملخص (tag->digest mapping).

إذا كنت تريد الإقرار بأن علامة معينة (أو مجموعة علامات) يجب أن تشير إلى ملخص معين، يمكنك
تشغيل شيء مثل:```shell
$ docker push $IMAGE_URI
The push refers to repository [dlorenc/demo]
994393dc58e7: Pushed
5m: digest: sha256:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870 size: 528
$ TAG=sign-me
$ cosign sign --key cosign.key -a tag=$TAG $IMAGE_URI_DIGEST
Enter password for private key:
Pushing signature to: dlorenc/demo:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870.sig

يمكن أيضًا إضافة الطوابع الزمنية هنا، لتنفيذ منع هجمات التجميد بأسلوب TUF.

### توقيع الصورة الأساسية/الطبقة

مرة أخرى، يمكن لـ `cosign` توقيع أي شيء في سجل.
يمكنك استخدام `cosign` لتوقيع صورة يُقصد استخدامها كصورة أساسية،
وتضمين تلك البيانات الوصفية للمصدر في الصور المشتقة الناتجة.
يمكن استخدام هذا لفرض أن الصورة مبنية من صورة أساسية مرخّصة.

فكرة تقريبية:
* تحتوي OCI manifests على قائمة مرتبة من `layer` `Descriptors`، والتي يمكن أن تحتوي على تعليقات توضيحية.
  انظر [هنا](https://github.com/opencontainers/image-spec/blob/master/manifest.md) للحصول على
  المواصفات.
* الصورة الأساسية هي قائمة مرتبة من الطبقات التي تُلحق بها طبقات أخرى، بالإضافة إلى
  كائن إعداد أولي يتم تعديله.
  * الصورة المشتقة حرة في حذف/إتلاف/إعادة إنشاء الإعداد بالكامل من صورتها الأساسية،
    لذا فإن توقيع الإعداد سيوفر قيمة محدودة.
* يمكننا توقيع المجموعة الكاملة من الطبقات الأساسية المرتبة، وإرفاق هذا التوقيع كتعليق توضيحي على
  الطبقة **الأخيرة** في الصورة الفرعية الناتجة.

هذا المثال manifest manifest يمثل صورة تم بناؤها من صورة أساسية بطبقتين.
تمت إضافة طبقة إضافية واحدة، لتكوين الصورة النهائية.```json
{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "size": 7023,
    "digest": "sha256:b5b2b2c507a0944348e0303114d8d93aaaa081732b86451d9bce1f432a537bc7"
  },
  "layers": [
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 32654,
      "digest": "sha256:9834876dcfb05cb167a5c24953eba58c4ac89b1adf57f28f2f9d09af107ee8f0"
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 16724,
      "digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b",
      "annotations": {
        "dev.cosign.signature.baseimage": "Ejy6ipGJjUzMDoQFePWixqPBYF0iSnIvpMWps3mlcYNSEcRRZelL7GzimKXaMjxfhy5bshNGvDT5QoUJ0tqUAg=="
      }
    },
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "size": 73109,
      "digest": "sha256:ec4b8955958665577945c89419d1af06b5f7636b4ac3da7f12184802ad867736"
    }
  ],
}

<!-- TODO: https://github.com/sigstore/cosign/issues/2333 -->

الآن أعطِ هذا التوقيع اسمًا لا يُنسى، ثم وقّع عليه:```shell
$ crane tag $(cosign triangulate $IMAGE_URI) mysignature
2021/02/15 20:22:55 dlorenc/demo:mysignature: digest: sha256:71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e size: 556
$ cosign sign --key cosign.key -a sig=counter dlorenc/demo:mysignature
Enter password for private key:
Pushing signature to: dlorenc/demo:sha256-71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e.sig
$ cosign verify --key cosign.pub dlorenc/demo:mysignature
{"Critical":{"Identity":{"docker-reference":""},"Image":{"Docker-manifest-digest":"71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e"},"Type":"cosign container image signature"},"Optional":{"sig":"counter"}}

## إيقاع الإصدارات

نُصدر الإصدارات حسب الحاجة. تُصدَر إصدارات التصحيح لإصلاح الأخطاء الصغيرة. وتُصدَر الإصدارات الثانوية
بشكل دوري عند إصلاح عدة أخطاء أو إضافة ميزات. كما ستُصدَر الإصدارات الرئيسية
عند وجود ميزات تتضمن تغييرات جذرية.

## الأمان

إذا اكتشفت أي مشكلات أمنية، فيُرجى الرجوع إلى [عملية
الأمان](https://github.com/sigstore/.github/blob/main/SECURITY.md) الخاصة بـ sigstore

## ملفات الحزمة في أصول إصدارات GitHub

تحتوي أصول إصدارات GitHub الخاصة بـ `cosign` على ملفات حزمة Sigstore التي ينتجها [GoReleaser](https://github.com/sigstore/cosign/blob/ac999344eb381ae91455b0a9c5c267e747608d76/.goreleaser.yml#L166) أثناء توقيع blob الخاص بـ cosign المستخدم للتحقق من سلامة الملفات الثنائية للإصدار.
لا يستخدم cosign هذا الملف بنفسه، لكنه يُوفَّر للمستخدمين الذين يرغبون في [التحقق من سلامة الملفات الثنائية للإصدار](https://docs.sigstore.dev/cosign/system_config/installation/#verifying-cosign-with-artifact-key).