नोट: git 2.5 तक, git verify-commitऔर git verify-tagकेवल एक मानव पठनीय संदेश प्रदर्शित करता है।
यदि आप चेक को स्वचालित करना चाहते हैं, तो git 2.6+ (Q3 2015) एक और आउटपुट जोड़ता है।
देखें e18443e प्रतिबद्ध , aeff29d प्रतिबद्ध , ca194d5 प्रतिबद्ध , 434060e प्रतिबद्ध , 8e98e5f प्रतिबद्ध , a4cc18f प्रतिबद्ध , d66aeff प्रतिबद्ध द्वारा (21 जून 2015) ब्रायन मीटर। कार्लसन ( bk2204) ।
(द्वारा विलय Junio सी Hamano - gitster- में ba12cb2 प्रतिबद्ध , 03 अगस्त 2015)
verify-tag/ verify-commit: कच्चे gpg स्थिति की जानकारी मुद्रित करने के लिए विकल्प जोड़ें
verify-tag/ verify-commitडिफ़ॉल्ट रूप से मानक त्रुटि पर मानव-पठनीय आउटपुट प्रदर्शित करता है।
हालाँकि, यह कच्चे gpg स्थिति की जानकारी तक पहुँच प्राप्त करने के लिए भी उपयोगी हो सकता है, जो कि मशीन-पठनीय है, जिससे हस्ताक्षरित नीति के स्वचालित कार्यान्वयन की अनुमति मिलती है ।
मानव-पठनीय प्रारूप के बजाय मानक त्रुटि पर gpg स्थिति की जानकारी का उत्पादन करने के लिए एक --rawविकल्प जोड़ें verify-tag।
प्लस:
verify-tagयदि हस्ताक्षर अच्छे हैं, लेकिन कुंजी अविश्वसनीय है तो सफलतापूर्वक बाहर निकलता है। verify-commitअसफलता से बाहर निकलता है।
व्यवहार में यह विचलन अप्रत्याशित और अवांछित है।
चूंकि verify-tagपहले मौजूद था, इसलिए verify-commitसाझा verify-tagव्यवहार के लिए एक असफल परीक्षा जोड़ें ।
git 2.9 (जून 2016) git मर्ज का अद्यतन करें :
Keller Fuchs (``) द्वारा प्रतिबद्ध 05a5869 (13 मई 2016) देखें ।
हेल्प-बाय: जूनियो सी हमानो ( ) । ( जूनियो सी हमानो द्वारा विलय - - in be6ec17 , 17 मई 2016)
gitster
gitster
--verify-signatures:
--no-verify-signatures:
सत्यापित करें कि साइड ब्रांच को मर्ज किए जाने वाले टिप कमेंट को एक वैध कुंजी के साथ हस्ताक्षरित किया गया है, अर्थात एक कुंजी जिसमें एक वैध यूआईडी है: डिफ़ॉल्ट ट्रस्ट मॉडल में, इसका मतलब है कि हस्ताक्षरित कुंजी को एक विश्वसनीय कुंजी द्वारा हस्ताक्षरित किया गया है।
यदि साइड ब्रांच के टिप कमिटमेंट को एक वैध कुंजी के साथ हस्ताक्षरित नहीं किया गया है, तो मर्ज निरस्त कर दिया जाता है ।
अपडेट 2.10 (Q3 2016)
Linus Torvalds ( ) द्वारा प्रतिबद्ध b624a3e (16 अगस्त 2016) देखें । ( जूनियो सी हमानो द्वारा विलय - - में 9३d9eb0 , १ ९ अगस्त २०१६)torvalds
gitster
gpg-interface: पीजीपी हस्ताक्षरों की पुष्टि करते समय "लंबी" कुंजी प्रारूप आउटपुट पसंद करते हैं
" git log --show-signature" और पीजीपी हस्ताक्षर की सत्यापन स्थिति को प्रदर्शित करने वाली अन्य कमांड अब कुंजी-आईडी दिखाती है, क्योंकि 32-बिट की-आईडी इतनी शताब्दी है।
लाइनस के मूल को केवल बाइनरी वितरकों को अतीत में फंसने के मामले में रखरखाव ट्रैक पर लागू करने के लिए छूट दी गई थी जो इसे अपने पुराने कोडबेस पर ले जाना चाहते हैं।
Git 2.11+ (Q4 2016) और भी अधिक सटीक होगा।
माइकल जे ग्रुबर ( ) द्वारा प्रतिबद्ध 661a180 (12 अक्टूबर 2016) देखें । (द्वारा विलय Junio सी Hamano - - में 56d268b प्रतिबद्ध , 26 अक्टू 2016)mjg
gitster
GPG सत्यापन स्थिति " %G?" में दिखाया गया है कि सुंदर प्रारूप विनिर्देशक पर्याप्त नहीं था कि वह समाप्त हो चुकी कुंजी द्वारा किए गए हस्ताक्षर को अलग करने के लिए पर्याप्त हो, एक निरस्त कुंजी द्वारा हस्ताक्षरित, आदि
नए आउटपुट पत्र उन्हें व्यक्त करने के लिए असाइन किए गए हैं ।
Gpg2 केdoc/DETAILS अनुसार :
प्रत्येक हस्ताक्षर कोड का केवल एक के लिए GOODSIG, BADSIG, EXPSIG, EXPKEYSIG, REVKEYSIGया ERRSIGउत्सर्जित कर दिया जाएगा।
git pretty-formatप्रलेखन अब में शामिल हैं:
- '
%G?': दिखाओ
- "
G" एक अच्छे (वैध) हस्ताक्षर के लिए,
- "
B" एक बुरे हस्ताक्षर के लिए,
- "
U" अज्ञात वैधता वाले अच्छे हस्ताक्षर के लिए,
- "
X" एक अच्छे हस्ताक्षर के लिए, जो समाप्त हो गया है,
- "
Y" एक समाप्त हो चुकी कुंजी द्वारा किए गए अच्छे हस्ताक्षर के लिए,
- "
R" निरस्त कुंजी द्वारा किए गए एक अच्छे हस्ताक्षर के लिए,
- "
E" अगर हस्ताक्षर की जांच नहीं की जा सकती है (जैसे गुम कुंजी) और बिना हस्ताक्षर के "एन"
Git 2.12 (Q1 2017) " git tag" और " git verify-tag" उनके " --format=<placeholders>" आउटपुट प्रारूप में GPG सत्यापन स्थिति डालना सीख गया ।
देखें 4fea72f प्रतिबद्ध , प्रतिबद्ध 02c5433 , प्रतिबद्ध ff3c8c8 (17 जनवरी 2017) द्वारा सैंटियागो टोरेस ( SantiagoTorres) ।
देखें 07d347c , 2111aa7 प्रतिबद्ध , 94240b9 (17 जनवरी 2017) को लुकास पुहिंगर (``) द्वारा ।
( जूनियो सी gitsterहमानो द्वारा विलय - - प्रतिबद्ध २३ , bdd9 , ३१ जनवरी २०१io में )
GPG सत्यापन के डिफ़ॉल्ट आउटपुट --formatको git tag -vम्यूट करने के लिए जोड़ना और इसके बजाय स्वरूपित टैग ऑब्जेक्ट प्रिंट करता है।
यह कॉल करने वालों को जीपीजी सत्यापन पर टैग ऑब्जेक्ट हेडर से टैग्नैम के साथ रेफल्स / टैग्स से टैग्नैम को क्रॉस-चेक करने की अनुमति देता है।
2.16 Git (Q1 2018) merge.verifySignaturesकॉन्फ़िगरेशन वेरिएबल के साथ प्रतिबद्ध हस्ताक्षर सत्यापन को और भी अधिक स्वचालित होने की अनुमति देगा ।
देखें प्रतिबद्ध 7f8ca20 , ca779e8 प्रतिबद्ध (10 दिसंबर 2017) से ( ``) हंस जेरी Illikainen ।
(द्वारा विलय Junio सी Hamano - gitster- में प्रतिबद्ध 0433d53 , 28 दिसंबर 2017)
merge: के लिए कॉन्फ़िगर विकल्प जोड़ें verifySignatures
git merge --verify-signatures यह सत्यापित करने के लिए उपयोग किया जा सकता है कि शाखा के टिप कमेंट को मर्ज किया जा रहा है, ठीक से हस्ताक्षरित है, लेकिन यह हर बार निर्दिष्ट करने के लिए बोझिल है।
एक कॉन्फ़िगरेशन विकल्प जोड़ें जो इस व्यवहार को डिफ़ॉल्ट रूप से सक्षम करता है, जिसे ओवरराइड किया जा सकता है --no-verify-signatures।
git mergeConfig आदमी पेज अब पढ़ता है:
merge.verifySignatures:
यदि सही है, तो यह --verify-signaturesकमांड लाइन विकल्प के बराबर है ।
Git 2.19 (Q3 2018) और भी अधिक सहायक है, क्योंकि " git verify-tag" और " git verify-commit" gpg --verifyखराब या अविश्वसनीय हस्ताक्षर को इंगित करने के लिए अंतर्निहित " " की निकास स्थिति का उपयोग करना सिखाया गया है।
नोट: Git 2.19, साथ gpg.format"करने के लिए सेट किया जा सकता है कि openpgp" या " x509", और gpg.<format>.programकि निर्दिष्ट करने के लिए के माध्यम से "क्या कार्यक्रम सीएमएस के साथ x.509 प्रमाणपत्र अनुमति देने के लिए) प्रारूप से निपटने के लिए उपयोग करने के लिए प्रयोग किया जाता है gpgsm" के बजाय प्रयोग की जाने वाली openpgpके माध्यम से " gnupg"।
देखें 4e5dc9c प्रतिबद्ध द्वारा (09 अगस्त 2018) Junio सी Hamano ( gitster) । हेल्प
-बाय: वोजटेक मैसिविवेक ( VojtechMyslivec) , ब्रायन एम। कार्लसन ( bk2204) , और जेफ किंग ( peff) ।
(द्वारा विलय Junio सी Hamano - gitster- में प्रतिबद्ध 4d34122 , 20 अगस्त 2018)
gpg-interface: gpgकॉल करने वालों को पीछे से बाहर निकलने की स्थिति का प्रचार करें
जब gpg-इंटरफ़ेस API ने हस्ताक्षरित टैग के लिए हस्ताक्षर सत्यापन कोडपथ के लिए एकीकृत समर्थन और v2.6.0-rc0 ~ 114 के मध्य में हस्ताक्षर किए, तो हमने गलती से GPG हस्ताक्षर सत्यापन को ढीला कर दिया।
उस परिवर्तन से पहले, हस्ताक्षरित कमिटों को " G" GPG से ood हस्ताक्षर gpg --verifyकी पुष्टि करके सत्यापित किया गया था, जबकि " " प्रक्रिया की निकास स्थिति की अनदेखी करते हुए, जबकि हस्ताक्षरित टैग को केवल "gpg --verify"से बाहर निकलने की स्थिति से गुजरते हुए " सत्यापित किया गया था।
एकीकृत कोड जिसे हम वर्तमान में " gpg --verify" के एक्जिट स्टेटस पर ध्यान नहीं देते हैं और सफल सत्यापन देता है जब हस्ताक्षर कुंजी पर रखे भरोसे के बिना एक अनपेक्षित कुंजी से मेल खाता है (अर्थात G" U" ओड के अलावा , हम स्वीकार करते हैं " " ntrusted वाले)।
इन कमांडों को उनके बाहर निकलने की स्थिति के साथ सिग्नल की विफलता बनाते हैं जब अंतर्निहित " gpg --verify" (या gpg.program"कॉन्फ़िगरेशन चर" द्वारा निर्दिष्ट कस्टम कमांड ऐसा करता है।
यह अनिवार्य रूप से उनके व्यवहार को एक पिछड़े असंगत तरीके से हस्ताक्षर को अस्वीकार करने के लिए बदल देता है जो अविश्वासित कुंजी के साथ किए गए हैं, भले ही वे सही तरीके से सत्यापित करें, जैसा कि " gpg --verify" व्यवहार करता है।
ध्यान दें कि कोड अभी भी " gpg" (या gpg.program) से प्राप्त शून्य निकास स्थिति को ओवरराइड करता है, अगर आउटपुट यह नहीं कहता कि हस्ताक्षर अच्छे हैं या सही तरीके से गणना करते हैं, लेकिन अविश्वासित कुंजियों के साथ बनाया गया है, gpgतो उपयोगकर्ता "हमें" दे सकता है। ।
हम Uइस फ़ॉलबैक कोड से " " ntrusted समर्थन को बाहर कर सकते हैं , लेकिन यह एक ही प्रतिबद्ध में दो पिछड़े असंगत परिवर्तन कर देगा, तो चलो अब के लिए इससे बचें।
यदि वांछित है तो एक अनुवर्ती परिवर्तन ऐसा कर सकता है।
किसी भी एन्क्रिप्शन को करने से पहले उस पर भरोसा किया जाना चाहिए
ट्रस्ट पक्ष में, प्रगति है:
2.26 Git (Q1 2020) के साथ, gpg.minTrustLevelकॉन्फ़िगरेशन चर को विभिन्न हस्ताक्षर सत्यापन कोडपाइयों को आवश्यक न्यूनतम विश्वास स्तर बताने के लिए पेश किया गया है।
हंस जेरी इलकीनेन ( ) द्वारा प्रतिबद्ध 54887b4 (27 दिसंबर 2019) देखें । (द्वारा विलय Junio सी Hamano - - में 11ad30b प्रतिबद्ध , 30 जनवरी 2020)illikainen
gitster
gpg-interface: एक विन्यास विकल्प के रूप में minTrustLevel जोड़ें
साइन-ऑफ-बाय: हंस जेरी इलकीनेन
इससे पहले, मर्ज और पुल के संचालन के लिए हस्ताक्षर सत्यापन जाँच करता है, तो कुंजी में से किसी एक ट्रस्ट स्तर के लिए किया था TRUST_NEVERया TRUST_UNDEFINEDमें verify_merge_signature()।
अगर ऐसा था, तो प्रक्रिया die()की d।
हस्ताक्षर सत्यापन करने वाले अन्य कोड पथ पूरी तरह से रिटर्न कोड पर निर्भर थे check_commit_signature()।
और एक अच्छी कुंजी के साथ किए गए हस्ताक्षर, अपने विश्वास के स्तर के बावजूद, द्वारा मान्य माना जाता था check_commit_signature()।
व्यवहार में यह अंतर हो सकता है ग़लती से ग्रहण करने के लिए है कि उनके कीरिंग में एक महत्वपूर्ण का विश्वास स्तर हमेशा Git द्वारा माना जाता है यहां तक कि संचालन के लिए (जैसे एक के दौरान उपयोगकर्ताओं के लिए प्रेरित है, जहां यह नहीं है verify-commitया verify-tag) ।
जिस तरह से यह काम किया है gpg-interface.cवह कुंजी / हस्ताक्षर की स्थिति से परिणाम को संग्रहीत करके था और के resultसदस्य में सबसे कम-दो ट्रस्ट स्तरों signature_check(इन स्थिति लाइनों के अंतिम जिन्हें लिखा गया था result) ।
ये उपधारा के तहत GPG में दर्ज कर रहे हैं General status codesऔर Key relatedक्रमश:।
GPG प्रलेखन कोड पर निम्नलिखित कहता हैTRUST_ status :
ये कई समान स्थिति कोड हैं:
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
अच्छे हस्ताक्षरों के लिए, हस्ताक्षर बनाने के लिए उपयोग की जाने वाली कुंजी की वैधता को इंगित करने के लिए इनमें से एक स्थिति रेखा का उत्सर्जन किया जाता है।
त्रुटि मान वर्तमान में केवल gpgsm द्वारा उत्सर्जित होते हैं।
मेरी व्याख्या यह है कि ट्रस्ट स्तर कुंजी और / या हस्ताक्षर की वैधता से वैचारिक रूप से भिन्न है।
ऐसा लगता है कि पुराने कोड की धारणा भी रही है check_signature()जहां ' G' (जैसा GOODSIG) और ' U' (के रूप में)TRUST_NEVER या केTRUST_UNDEFINED) एक सफलता माना जाता था।
जिन दो मामलों के परिणाम में ' U' का विशेष अर्थ था verify_merge_signature()(जहां यह कारण gitथा die()) और format_commit_one()(जहां इसका उत्पादन प्रभावित हुआ )%G? प्रारूप विनिर्देश करता है) में थे।
मुझे लगता है कि यह TRUST_ statusलाइनों के प्रसंस्करण को फिर से बनाने के लिए समझ में आता है ताकि उपयोगकर्ता एक न्यूनतम विश्वास स्तर को कॉन्फ़िगर कर सकें जो विश्व स्तर पर लागू हो, बजाय व्यक्तिगत भागों केgit (जैसे मर्ज) इसे स्वयं करते हैं (पिछड़े संगतता के साथ एक अनुग्रह अवधि को छोड़कर)।
मुझे यह भी लगता है कि यह कुंजी / हस्ताक्षर की स्थिति के रूप में एक ही संरचना के सदस्य में विश्वास स्तर को स्टोर नहीं करने के लिए समझ में आता है।
हालांकि एक TRUST_ statusकोड की उपस्थिति का मतलब यह है कि हस्ताक्षर अच्छा है (ऊपर दिए गए स्निपेट में पहला पैराग्राफ देखें), जहां तक मैं बता सकता हूं, जीपीजी से स्थिति लाइनों का क्रम अच्छी तरह से परिभाषित नहीं है; इस प्रकार यह प्रशंसनीय प्रतीत होगा कि ट्रस्ट स्तर को कुंजी / हस्ताक्षर की स्थिति के साथ अधिलेखित किया जा सकता है यदि उन्हें signature_checkसंरचना के एक ही सदस्य में संग्रहीत किया गया हो ।
यह पैच एक नया कॉन्फ़िगरेशन विकल्प प्रस्तुत करता है gpg.minTrustLevel:।
यह ट्रस्ट-स्तरीय सत्यापन को समेकित करता है gpg-interface.cऔर संरचना में एक नया trust_levelसदस्य जोड़ता है signature_check।
बैकवर्ड-कम्पैटिबिलिटी को एक विशेष मामले में verify_merge_signature()इस तरह से पेश करके बनाए रखा जाता है कि यदि कोई उपयोगकर्ता-कॉन्फ़िगर करने gpg.minTrustLevelयोग्य सेट नहीं है, तो अस्वीकार करने का पुराना व्यवहार TRUST_UNDEFINEDऔर TRUST_NEVERलागू किया जाता है।
यदि, दूसरी ओर, gpg.minTrustLevelसेट किया गया है, तो वह मूल्य पुराने व्यवहार को ओवरराइड करता है।
इसी प्रकार, %G?प्रारूप निर्दिष्ट Uएक कुंजी के साथ किए गए हस्ताक्षरों के लिए शो ' ' को जारी रखेगा , जिसका विश्वास स्तर है TRUST_UNDEFINEDया TRUST_NEVER,भले ही ' U' चरित्र संरचना के resultसदस्य में मौजूद नहीं है signature_check।
एक नया प्रारूप विनिर्देशक, %GTउन उपयोगकर्ताओं के लिए भी प्रस्तुत किया गया है, जो हस्ताक्षर के लिए सभी संभव ट्रस्ट स्तर दिखाना चाहते हैं।
एक अन्य दृष्टिकोण केवल विश्वास-स्तर की आवश्यकता को छोड़ने के लिए होता verify_merge_signature() ।
यह व्यवहार के अन्य भागों के अनुरूप भी बना होगा जो हस्ताक्षर सत्यापन करते हैं।
हालाँकि, कुंजी पर हस्ताक्षर करने के लिए एक न्यूनतम विश्वास स्तर की आवश्यकता वास्तविक-विश्व उपयोग के मामले में है।
उदाहरण के लिए, क्यूब्स ओएस परियोजना द्वारा उपयोग की जाने वाली बिल्ड सिस्टम वर्तमान में गित टैग पर हस्ताक्षर करने के लिए उपयोग की जाने वाली कुंजियों के लिए न्यूनतम विश्वास स्तर को सुनिश्चित करने के लिए सत्यापित-टैग से कच्चे आउटपुट को पार्स करती है ।
git config gpgआदमी पेज अब में शामिल हैं:
gpg.minTrustLevel:
हस्ताक्षर सत्यापन के लिए एक न्यूनतम विश्वास स्तर निर्दिष्ट करता है।
यदि यह विकल्प परेशान है, तो मर्ज संचालन के लिए हस्ताक्षर सत्यापन के लिए कम से कम marginalविश्वास के साथ एक कुंजी की आवश्यकता होती है ।
हस्ताक्षर सत्यापन करने वाले अन्य कार्यों में कम से कम undefinedविश्वास के साथ एक कुंजी की आवश्यकता होती है ।
इस विकल्प को सेट करना सभी ऑपरेशनों के लिए आवश्यक विश्वास-स्तर को ओवरराइड करता है। समर्थित मूल्य, महत्व के बढ़ते क्रम में:
undefinednevermarginalfullyultimate
साथ Git 2.26 (क्यू 1 2020) , " git show" और दूसरों को एक वस्तु नाम अपने त्रुटि उत्पादन है, जो हेक्स में इसे देने के लिए सही किया गया है में कच्चे प्रारूप में दे दी है।
show_one_mergetag: गैर-अभिभावक को हेक्स रूप में मुद्रित करें।
जब एक मर्जेट एक गैर-अभिभावक का नाम देता है, जो उथले क्लोन के बाद हो सकता है, तो इसका हैश पहले कच्चे डेटा के रूप में मुद्रित किया गया था।
इसके बजाय हेक्स रूप में प्रिंट करें।
git -C shallow log --graph --show-signature -n1 plain-shallowएक के बाद के साथ परीक्षण किया गयाgit clone --depth 1 --no-local . shallow
2.27 Git (Q2 2020) के साथ, GnuPG के साथ इंटरफेस कोड को फिर से चालू किया गया है।
6664898 के लिए प्रतिबद्ध देखें , हंस जेरी इलेनकेन ( ) द्वारा f1e3df3 (04 मार्च 2020) के लिए प्रतिबद्ध । (द्वारा विलय Junio सी Hamano - - में प्रतिबद्ध fa82be9 , 27 मार्च 2020)illikainen
gitster
gpg-interface: check_signature()GPG सत्यापन के लिए प्राथमिकता दें
साइन-ऑफ-बाय: हंस जेरी इलकीनेन
यह refactors के उपयोग के लिए प्रतिबद्ध verify_signed_buffer()बाहर का gpg-interface.cउपयोग करने के लिए check_signature()बजाय।
यह verify_signed_buffer()फ़ाइल-स्थानीय फ़ंक्शन में भी बदल जाता है क्योंकि यह अब केवल आंतरिक रूप से लागू होता हैcheck_signature() ।
पहले GPG के हस्ताक्षर सत्यापन को करने के लिए Git के विभिन्न भागों में उपयोग किए जाने वाले दो वैश्विक स्तर पर स्कोप किए गए कार्य थे: verify_signed_buffer()और check_signature()।
अब केवल check_signature()उपयोग किया जाता है।
यह verify_signed_buffer()फ़ंक्शन डुप्लिकेट हस्ताक्षरों के विरुद्ध नहीं है, जैसा कि मिशेल गॉनी द्वारा वर्णित है ।
इसके बजाय यह केवल GPG से एक गैर-गलत निकास कोड और कम से कम एक GOODSIGस्थिति फ़ील्ड की उपस्थिति सुनिश्चित करता है ।
check_signature()यदि एक से अधिक हस्ताक्षर सामने आते हैं, तो इसके विपरीत यह एक त्रुटि है।
सत्यापन की निचली डिग्री verify_signed_buffer()समस्याग्रस्त का उपयोग करती है अगर कॉलर्स पार्स नहीं करते हैं और जीपीजी स्थिति संदेश के विभिन्न भागों को स्वयं सत्यापित करते हैं।
और इन संदेशों को संसाधित करना एक कार्य की तरह लगता है gpg-interface.cजिसे फ़ंक्शन के साथ आरक्षित किया जाना चाहिए check_signature()।
इसके अलावा, verify_signed_buffer()नई कार्यक्षमता को पेश करना मुश्किल बनाता है जो GPG स्थिति लाइनों की सामग्री पर निर्भर करता है।
अब सभी सत्यापन जो हस्ताक्षर सत्यापन करते हैं, वे एकल प्रविष्टि बिंदु को साझा करते हैं gpg-interface.c।
इससे Git के सभी भागों में GPG के हस्ताक्षर सत्यापन में परिवर्तित या अतिरिक्त कार्यक्षमता का प्रसार करना आसान हो जाता है, बिना विषम धार वाले मामले जो सत्यापन के समान डिग्री का प्रदर्शन नहीं करते हैं ।
git commit ...औरgit log ...। जहां तक मुझे पता है, सबgpg-बैंड्स को नहीं जोड़ा है जोgitपारदर्शी रूप से पास हो जाते हैं ... मेरे पास परीक्षण करने के लिए कोई रिपॉज नहीं है, लेकिनgit show --show-signature <commitish>काम करता है ?