## योगदान देना

यदि आप `cosign` में योगदान देने में रुचि रखते हैं, तो कृपया [योगदान दस्तावेज़ीकरण](https://github.com/sigstore/cosign/blob/HEAD/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 एक स्थिर रिलीज़ है और इसे समय-समय पर सुविधा अद्यतन और बग फिक्स प्राप्त होते रहेंगे। छोटे दायरे और आकार वाले PRs की त्वरित समीक्षा होने की सबसे अधिक संभावना है।

जो PRs API में महत्वपूर्ण रूप से संशोधन या तोड़-फोड़ करते हैं, उन्हें स्वीकार नहीं किया जाएगा। जो PRs आकार में महत्वपूर्ण हैं लेकिन ब्रेकिंग परिवर्तन नहीं लाते हैं, उन्हें स्वीकार किया जा सकता है, लेकिन sigstore-go में PRs की तुलना में उन्हें कम प्राथमिकता माना जाएगा।

## Dockerfile

Dockerfile के माध्यम से ghcr.io/sigstore/cosign/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 रिपॉजिटरी से समय-समय पर सेवा कुंजियों का अनुरोध करना आवश्यक होता है।
सार्वजनिक-अच्छे इंस्टेंस का उपयोग करके हस्ताक्षरों के एयरगैप सत्यापन के लिए, आपको प्रोडक्शन TUF रिपॉजिटरी से [trusted root](https://github.com/sigstore/root-signing/blob/main/targets/trusted_root.json) फ़ाइल प्राप्त करनी होगी। इस फ़ाइल की सामग्री बिना सूचना के बदल जाएगी। TUF का उपयोग न करने पर, आपको इस फ़ाइल की अपनी एयरगैप कॉपी को अद्यतित रखने के लिए अपना स्वयं का तंत्र बनाना होगा।

Cosign एक [बंडल](https://github.com/sigstore/cosign/blob/HEAD/specs/SIGNATURE_SPEC.md#properties) को सत्यापित करके पूरी तरह से ऑफलाइन सत्यापन कर सकता है, जो आमतौर पर इमेज मैनिफेस्ट पर एक एनोटेशन के रूप में वितरित किया जाता है।
जब तक यह एनोटेशन मौजूद है, तब तक ऑफलाइन सत्यापन किया जा सकता है।
यह बंडल एनोटेशन डिफ़ॉल्ट रूप से कुंजी रहित हस्ताक्षर के लिए हमेशा शामिल किया जाता है, इसलिए डिफ़ॉल्ट `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 सेवाओं पर निर्भर करता है। यदि इनमें से कोई भी सेवा विफल हो जाती है तो विफलता पर पुनः प्रयास करना एक उपयोगी समाधान हो सकता है -- विशिष्ट विफलताओं के लिए मुद्दे दर्ज करना भी सराहनीय है

#### मेरी समस्या कुछ और है

कृपया एक [मुद्दा](https://github.com/sigstore/cosign/issues/new/choose) खोलें या [स्लैक चैनल](#info) में पूछें।

## अन्य आर्टिफैक्ट्स के साथ काम करना

OCI रजिस्ट्रियाँ केवल कंटेनर इमेज से अधिक संग्रहीत करने के लिए उपयोगी हैं!
`Cosign` में OCI प्रोटोकॉल का उपयोग करके सामान्य आर्टिफैक्ट्स, जिनमें बाइनरी, स्क्रिप्ट और कॉन्फ़िगरेशन फ़ाइलें शामिल हैं, प्रकाशित करने के लिए कुछ उपयोगिताएँ भी शामिल हैं।

यह अनुभाग दिखाता है कि कैसे इनका लाभ उठाकर एक उपयोग में आसान, पश्च-संगत आर्टिफैक्ट वितरण प्रणाली बनाई जाए जो Sigstore के बाकी हिस्सों के साथ अच्छी तरह से एकीकृत होती है।

अधिक जानकारी के लिए [दस्तावेज़ीकरण](https://docs.sigstore.dev/cosign/signing/other_types/) देखें।

### ब्लॉब्स

आप `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 में बेक किया गया है, इसलिए वे उसे भी जांच सकते हैं:```shell
$ cat artifact-fetched | shasum -a 256
c69d72c98b55258f9026f984e4656f0e9fd3ef024ea3fac1d7e5c7e6249f1626  -

हमेशा की तरह, सुनिश्चित करें कि आपके द्वारा हस्ताक्षरित किसी भी छवि को उसके डाइजेस्ट से संदर्भित करें ताकि यह सुनिश्चित हो सके कि आप गलत चीज़ पर हस्ताक्षर नहीं कर रहे हैं!

#### Tekton Bundles

Tekton बंडलों को OCI रजिस्ट्री के भीतर अपलोड और प्रबंधित किया जा सकता है।
विनिर्देश [यहाँ](https://tekton.dev/docs/pipelines/tekton-bundle-contracts/) है।
इसका मतलब है कि उन पर `cosign` के साथ हस्ताक्षर और सत्यापन भी किया जा सकता है।

Tekton Bundles को वर्तमान में [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 हैश का उपयोग करता है, दोनों अस्थायी कुंजी रहित हस्ताक्षर और प्रबंधित कुंजी हस्ताक्षर के लिए।
कुंजियाँ PEM-एन्कोडेड PKCS8 प्रारूप में संग्रहीत की जाती हैं।
हालाँकि, आप किसी भी एल्गोरिदम से किसी भी प्रारूप में हस्ताक्षर संग्रहीत करने और पुनर्प्राप्त करने के लिए `cosign` का उपयोग कर सकते हैं।

### वे चीज़ें जो शायद बदलनी चाहिएँ

#### पेलोड प्रारूप

`cosign` केवल Red Hat के [सरल हस्ताक्षर](https://www.redhat.com/en/blog/container-image-signing) प्रारूप का समर्थन करता है पेलोड के लिए।
यह इस प्रकार दिखता है:```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

सार्वजनिक कुंजियाँ डिस्क पर PEM-एन्कोडेड मानक PKIX प्रारूप में `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

## FAQ

### Notary v2 का उपयोग क्यों नहीं करें?

इसका संक्षेप में उत्तर देना कठिन है।
इस पोस्ट में कुछ तुलनाएँ हैं:

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

यदि आपको अन्य तुलना पोस्ट मिलें, तो कृपया यहाँ PR भेजें और हम उन सभी को लिंक कर देंगे।

### containers/image हस्ताक्षर का उपयोग क्यों नहीं करें?

`containers/image` हस्ताक्षर `cosign` के करीब है, और हम पेलोड प्रारूपों का पुन: उपयोग करते हैं।
`cosign` इस मायने में भिन्न है कि यह PGP के बजाय ECDSA-P256 कुंजियों से हस्ताक्षर करता है, और
हस्ताक्षरों को रजिस्ट्री में संग्रहीत करता है।

### TUF का उपयोग क्यों नहीं करें?

मेरा मानना है कि यह उपकरण TUF का पूरक है, और इन्हें एक साथ उपयोग किया जा सकता है।
मैंने अभी तक प्रयास नहीं किया है, लेकिन सोचता हूँ कि हम TUF भंडारण के लिए भी रजिस्ट्री का पुन: उपयोग कर सकते हैं।

## डिज़ाइन आवश्यकताएँ

* हस्ताक्षर भंडारण, क्वेरी या पुनर्प्राप्ति के लिए कोई बाहरी सेवाएँ नहीं
* हम जितना संभव हो उतना रजिस्ट्री समर्थन का लक्ष्य रखते हैं
* सब कुछ रजिस्ट्री API पर काम करना चाहिए
* PGP की बिल्कुल आवश्यकता नहीं होनी चाहिए।
* उपयोगकर्ताओं को एक इमेज के सभी हस्ताक्षर खोजने में सक्षम होना चाहिए
* हस्ताक्षरकर्ता पुश के बाद इमेज पर हस्ताक्षर कर सकते हैं
* कई संस्थाएँ एक इमेज पर हस्ताक्षर कर सकती हैं
* इमेज पर हस्ताक्षर करने से इमेज परिवर्तित नहीं होती
* शुद्ध-गो कार्यान्वयन

## भविष्य के विचार

### रजिस्ट्री API परिवर्तन

रजिस्ट्री में चीज़ों को संग्रहीत करने के लिए हम जिन नामकरण परंपरा और पढ़ें-संशोधित-लिखें अद्यतन पैटर्न का उपयोग करते हैं, वे थोड़े, ठीक है, 'हैकी' हैं।
मुझे लगता है कि वे आज उपलब्ध सबसे अच्छे (एकमात्र) वास्तविक विकल्प हैं, लेकिन यदि रजिस्ट्री API
बदलता है तो हम इनमें सुधार कर सकते हैं।

### अन्य प्रकार

`cosign` रजिस्ट्री में किसी भी चीज़ पर हस्ताक्षर कर सकता है।
ये उदाहरण एक एकल इमेज पर हस्ताक्षर करना दिखाते हैं, लेकिन आप एक मल्टी-प्लेटफ़ॉर्म `Index`,
या किसी भी अन्य प्रकार की कलाकृति पर भी हस्ताक्षर कर सकते हैं।
इसमें Helm Charts, Tekton Pipelines, और वितरण के लिए वर्तमान में OCI रजिस्ट्रियों का उपयोग करने वाली कोई भी अन्य चीज़ शामिल है।

इसका अर्थ यह भी है कि नए कलाकृति प्रकारों को रजिस्ट्री में अपलोड और हस्ताक्षरित किया जा सकता है।
संग्रहीत और हस्ताक्षर करने के लिए एक दिलचस्प प्रकार TUF रिपॉजिटरी होगी।
मैंने अभी तक प्रयास नहीं किया है, लेकिन मुझे काफी यकीन है कि TUF को इसके ऊपर लागू किया जा सकता है।

### टैग हस्ताक्षर

`cosign` हस्ताक्षर रजिस्ट्री में संग्रहीत वस्तुओं के डाइजेस्ट की रक्षा करते हैं।
वैकल्पिक `annotations` समर्थन (`cosign sign` के `-a` फ़्लैग के माध्यम से) का उपयोग हस्ताक्षरित और हस्ताक्षर द्वारा संरक्षित पेलोड में अतिरिक्त डेटा जोड़ने के लिए किया जा सकता है।
इसका एक उपयोग-मामला टैग->डाइजेस्ट मैपिंग पर हस्ताक्षर करना हो सकता है।

यदि आप प्रमाणित करना चाहते हैं कि एक विशिष्ट टैग (या टैग का सेट) एक डाइजेस्ट की ओर इंगित करना चाहिए, तो आप
कुछ इस प्रकार चला सकते हैं:```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

Timestamps could also be added here, to implement TUF-style freeze-attack prevention.

### Base Image/Layer Signing

Again, `cosign` can sign anything in a registry.
You could use `cosign` to sign an image that is intended to be used as a base image,
and include that provenance metadata in resulting derived images.
This could be used to enforce that an image was built from an authorized base image.

Rough Idea:
* OCI manifests have an ordered list of `layer` `Descriptors`, which can contain annotations.
  See [here](https://github.com/opencontainers/image-spec/blob/master/manifest.md) for the
  specification.
* A base image is an ordered list of layers to which other layers are appended, as well as an
  initial configuration object that is mutated.
  * A derived image is free to completely delete/destroy/recreate the config from its base image,
    so signing the config would provided limited value.
* We can sign the full set of ordered base layers, and attach that signature as an annotation to
  the **last** layer in the resulting child image.

This example manifest manifest represents an image that has been built from a base image with two
layers.
One additional layer is added, forming the final image.```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"}}

## रिलीज़ आवृत्ति

हम आवश्यकतानुसार रिलीज़ करते हैं। पैच रिलीज़ छोटे बग ठीक करने के लिए जारी की जाती हैं। माइनर रिलीज़ समय-समय पर जारी की जाती हैं जब कई बग ठीक होते हैं या सुविधाएँ जोड़ी जाती हैं। मेजर रिलीज़ तब जारी की जाएंगी जब ब्रेकिंग सुविधाएँ हों।

## सुरक्षा

यदि आप कोई सुरक्षा समस्या पाते हैं, तो कृपया sigstore के [सुरक्षा प्रक्रिया](https://github.com/sigstore/.github/blob/main/SECURITY.md) का संदर्भ लें।

## GitHub रिलीज़ एसेट्स में बंडल फ़ाइलें

`cosign` के GitHub रिलीज़ एसेट्स में [GoReleaser](https://github.com/sigstore/cosign/blob/ac999344eb381ae91455b0a9c5c267e747608d76/.goreleaser.yml#L166) द्वारा उत्पन्न Sigstore बंडल फ़ाइलें शामिल हैं, जो रिलीज़ बाइनरी की अखंडता को सत्यापित करने के लिए उपयोग किए जाने वाले cosign ब्लॉब पर हस्ताक्षर करते समय बनाई गई हैं। यह फ़ाइल cosign द्वारा स्वयं उपयोग नहीं की जाती है, बल्कि उन उपयोगकर्ताओं के लिए प्रदान की जाती है जो [रिलीज़ बाइनरी की अखंडता सत्यापित](https://docs.sigstore.dev/cosign/system_config/installation/#verifying-cosign-with-artifact-key) करना चाहते हैं।