ด้วยเวอร์ชันที่ใหม่กว่าgitคุณสามารถลงนามคอมมิตแต่ละรายการ (นอกเหนือจากแท็ก) ด้วยคีย์ PGP:

git commit -m "some message" -S

และคุณสามารถแสดงลายเซ็นเหล่านี้ในผลลัพธ์git logด้วย--show-signatureตัวเลือก:

$ git log --show-signature
commit 93bd0a7529ef347f8dbca7efde43f7e99ab89515
gpg: Signature made Fri 28 Jun 2013 02:28:41 PM EDT using RSA key ID AC1964A8
gpg: Good signature from "Lars Kellogg-Stedman <lars@seas.harvard.edu>"
Author: Lars Kellogg-Stedman <lars@seas.harvard.edu>
Date:   Fri Jun 28 14:28:41 2013 -0400

    this is a test

แต่มีวิธีตรวจสอบลายเซ็นโดยทางโปรแกรมบนคอมมิตที่กำหนดนอกเหนือจากการ grepping ผลลัพธ์ของgit log? ฉันกำลังมองหาสิ่งที่เทียบเท่าการกระทำของgit tag -v- สิ่งที่จะให้รหัสออกเพื่อระบุว่ามีลายเซ็นที่ถูกต้องในการกระทำที่กำหนดหรือไม่

ในกรณีที่มีคนเข้ามาที่หน้านี้โดยใช้เครื่องมือค้นหาเช่นฉัน: เครื่องมือใหม่ได้รับการเผยแพร่ในช่วงสองปีนับตั้งแต่มีการโพสต์คำถาม: ขณะนี้มีคำสั่ง git สำหรับงานนี้: git verify-commitและgit verify-tagสามารถใช้เพื่อตรวจสอบการกระทำและ แท็กตามลำดับ

หมายเหตุ: สูงสุด 2.5 git verify-commitและgit verify-tagแสดงเฉพาะข้อความที่มนุษย์อ่านได้
หากคุณต้องการตรวจสอบโดยอัตโนมัติ git 2.6+ (Q3 2015) จะเพิ่มผลลัพธ์อื่น

ดูการกระทำ e18443e , กระทำ aeff29d , กระทำ ca194d5 , กระทำ 434060e , กระทำ 8e98e5f , กระทำ a4cc18f , กระทำ d66aeff (21 มิ.ย. 2558) โดยbrian m. คาร์ลสัน ( bk2204) .
^{(ผสานโดยJunio ​​C Hamano - gitster-ในการกระทำ ba12cb2 , 03 ส.ค. 2015)}

verify-tag/ verify-commit: เพิ่มตัวเลือกในการพิมพ์ข้อมูลสถานะ gpg ดิบ

verify-tag/ verify-commitโดยค่าเริ่มต้นจะแสดงเอาต์พุตที่มนุษย์อ่านได้เมื่อเกิดข้อผิดพลาดมาตรฐาน
อย่างไรก็ตามการเข้าถึงข้อมูลสถานะ gpg ดิบซึ่งสามารถอ่านได้โดยเครื่องทำให้สามารถใช้นโยบายการลงนามโดยอัตโนมัติได้เช่นกัน

เพิ่ม--rawตัวเลือกเพื่อverify-tagสร้างข้อมูลสถานะ gpg เกี่ยวกับข้อผิดพลาดมาตรฐานแทนรูปแบบที่มนุษย์อ่านได้

บวก:

verify-tagออกจากระบบสำเร็จหากลายเซ็นดี แต่คีย์ไม่น่าเชื่อถือ verify-commitออกไม่สำเร็จ
ความแตกต่างในพฤติกรรมนี้เป็นสิ่งที่ไม่คาดคิดและไม่ต้องการ
นับตั้งแต่verify-tagที่มีอยู่ก่อนหน้านี้เพิ่มการทดสอบล้มเหลวที่จะมีverify-commitส่วนแบ่งverify-tagพฤติกรรมของ

git 2.9 (มิถุนายน 2016) อัปเดตเอกสารgit merge :

ดูกระทำ 05a5869 (13 พฤษภาคม 2016) โดยเคลเลอร์ฟุกส์ ( ``)
ช่วยโดย: Junio C Hamano (gitster )
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ be6ec17 , 17 พฤษภาคม 2016)}

--verify-signatures:
--no-verify-signatures:

ตรวจสอบว่าทิปคอมมิตของสาขาด้านข้างที่ถูกผสานลงนามด้วยคีย์ที่ถูกต้องนั่นคือคีย์ที่มี uid ที่ถูกต้อง: ในรูปแบบความเชื่อถือเริ่มต้นหมายความว่าคีย์การลงนามได้รับการเซ็นชื่อโดยคีย์ที่เชื่อถือได้
ถ้าปลายกระทำของสาขาข้างเคียงที่ไม่ได้เซ็นสัญญากับคีย์ที่ถูกต้องผสานถูกยกเลิก

อัปเดต Git 2.10 (ไตรมาส 3 ปี 2559)

ดูกระทำ b624a3e (16 สิงหาคม 2016) โดยLinus Torvalds (torvalds )
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 83d9eb0 , 19 สิงหาคม 2016)}

gpg-interface: ชอบเอาต์พุตรูปแบบคีย์ "ยาว" เมื่อตรวจสอบลายเซ็น pgp

" git log --show-signature" และคำสั่งอื่น ๆ ที่แสดงสถานะการตรวจสอบลายเซ็น PGP ตอนนี้แสดงคีย์ - ไอดีที่ยาวขึ้นเนื่องจากคีย์ - ไอดี 32 บิตมีอายุยาวนานมาก

ต้นฉบับของ Linus ได้รับการปรับเปลี่ยนใหม่เพื่อใช้กับแทร็กการบำรุงรักษาในกรณีที่ผู้จัดจำหน่ายไบนารีที่ติดอยู่ในอดีตต้องการนำไปใช้กับโค้ดเบสที่เก่ากว่า

Git 2.11+ (ไตรมาส 4 ปี 2016) จะแม่นยำยิ่งขึ้น

ดูกระทำ 661a180 (12 ตุลาคม 2016) โดยไมเคิลเจกรูเบอร์ (mjg )
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 56d268b , 26 ตุลาคม 2016)}

สถานะการยืนยันจีพีจีที่แสดงใน " %G?" ระบุรูปแบบสวยก็ไม่มากพอที่อุดมไปด้วยความแตกต่างของลายเซ็นที่ทำโดยคีย์หมดอายุลายเซ็นที่ทำโดยคีย์เพิกถอน ฯลฯจดหมายส่งออกใหม่ได้รับมอบหมายให้ไปแสดงให้พวกเขา

ตามgpg2'sdoc/DETAILS :

สำหรับแต่ละลายเซ็นเพียงหนึ่งของรหัสที่GOODSIG, BADSIG, EXPSIG, EXPKEYSIG, REVKEYSIGหรือERRSIGจะถูกปล่อยออกมา

git pretty-formatเอกสารในขณะนี้รวมถึง:

• ' %G?': แสดง
  • " G" สำหรับลายเซ็นที่ดี (ถูกต้อง)
  • " B" สำหรับลายเซ็นที่ไม่ดี
  • " U" สำหรับลายเซ็นที่ดีโดยไม่ทราบความถูกต้อง
  • " X" สำหรับลายเซ็นที่ดีที่หมดอายุแล้ว
  • " Y" สำหรับลายเซ็นที่ดีจากคีย์ที่หมดอายุ
  • " R" สำหรับลายเซ็นที่ดีจากคีย์ที่ถูกเพิกถอน
  • " E" หากไม่สามารถตรวจสอบลายเซ็นได้ (เช่นคีย์ที่หายไป) และ "N" หากไม่มีลายเซ็น

Git 2.12 (ไตรมาสที่ 1 ปี 2017) " git tag" และ " git verify-tag" เรียนรู้ที่จะวางสถานะการยืนยันจีพีจีใน "ของพวกเขา--format=<placeholders>" รูปแบบการออก

ดูกระทำ 4fea72f , กระทำ 02c5433 , กระทำ ff3c8c8 (17 มกราคม 2017) โดยซันติอาโก Torres (SantiagoTorres )
ดูกระทำ 07d347c , กระทำ 2111aa7 , กระทำ 94240b9 (17 มกราคม 2017) โดยLukas Puehringer ( ``)
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 237bdd9 , 31 มกราคม 2017)}

การเพิ่ม--formatเพื่อgit tag -vปิดเอาต์พุตเริ่มต้นของการตรวจสอบ GPG และพิมพ์ออบเจ็กต์แท็กที่จัดรูปแบบแทน
สิ่งนี้ช่วยให้ผู้โทรสามารถตรวจสอบ tagname จาก refs / tags ด้วย tagname จากส่วนหัวแท็กเมื่อตรวจสอบ GPG

Git 2.16 (Q1 2018) จะช่วยให้การยืนยันลายเซ็นคอมมิตเป็นแบบอัตโนมัติยิ่งขึ้นด้วยmerge.verifySignaturesตัวแปรการกำหนดค่า

ดูกระทำ 7f8ca20 , กระทำ ca779e8 (10 ธันวาคม 2017) โดยฮันส์เจอร์รี่ Illikainen ( ``)
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 0433d53 , 28 ธันวาคม 2017)}

merge: เพิ่มตัวเลือกการกำหนดค่าสำหรับ verifySignatures

git merge --verify-signatures สามารถใช้เพื่อตรวจสอบว่าทิปคอมมิตของสาขาที่ถูกรวมเข้าได้รับการลงนามอย่างถูกต้อง แต่ก็ยุ่งยากที่จะต้องระบุทุกครั้ง

--no-verify-signaturesเพิ่มตัวเลือกการกำหนดค่าที่ช่วยให้การทำงานนี้โดยค่าเริ่มต้นซึ่งสามารถแทนที่โดย

git mergeหน้าคนการตั้งค่าในขณะนี้อ่าน:

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 ที่มี CMS ผ่าน " gpgsm" แทนopenpgpผ่าน " gnupg".

ดูกระทำ 4e5dc9c (9 สิงหาคม 2018) โดยJunio C Hamano (gitster )
ช่วยเหลือโดย: Vojtech Myslivec ( VojtechMyslivec) , brian m. คาร์ลสัน ( bk2204)และเจฟฟ์คิง (peff )
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 4d34122 , 20 สิงหาคม 2018)}

gpg-interface: เผยแพร่สถานะการออกจากgpgด้านหลังไปยังผู้โทร

เมื่อ gpg-interface API รวมการสนับสนุนสำหรับ codepath การตรวจสอบลายเซ็นสำหรับแท็กที่ลงชื่อและเซ็นสัญญาในกลางปี ​​2015 ที่ประมาณ v2.6.0-rc0 ~ 114 เราได้คลายการตรวจสอบลายเซ็น GPG โดยไม่ได้ตั้งใจ

ก่อนการเปลี่ยนแปลงนั้นได้มีการตรวจสอบข้อผูกมัดที่ลงนามโดยมองหาGลายเซ็น" " ood จาก GPG ในขณะที่ไม่สนใจสถานะการออกของgpg --verifyกระบวนการ "" ในขณะที่แท็กที่ลงชื่อจะได้รับการยืนยันโดยเพียงแค่ส่งสถานะการออกจาก"gpg --verify"ผ่าน

ขณะนี้รหัสรวมที่เราได้ละเว้นสถานะการออกของ " gpg --verify" และส่งคืนการตรวจสอบที่ประสบความสำเร็จเมื่อลายเซ็นตรงกับคีย์ที่ยังไม่หมดอายุโดยไม่คำนึงถึงความไว้วางใจที่วางอยู่บนคีย์ (เช่นนอกเหนือจาก " G" คนที่Uเชื่อถือได้เรายอมรับ " " คนที่ไม่น่าเชื่อถือ)

ทำให้คำสั่งเหล่านี้ส่งสัญญาณล้มเหลวด้วยสถานะการออกเมื่ออยู่ภายใต้ " gpg --verify" (หรือคำสั่งที่กำหนดเองที่ระบุโดยgpg.programตัวแปรคอนฟิกูเรชัน ")
โดยพื้นฐานแล้วสิ่งนี้จะเปลี่ยนพฤติกรรมของพวกเขาไปในทางที่ไม่สามารถใช้ร่วมกันได้ในการปฏิเสธลายเซ็นที่สร้างขึ้นด้วยคีย์ที่ไม่น่าเชื่อถือแม้ว่าจะมีการตรวจสอบอย่างถูกต้องก็ตามนั่นคือgpg --verifyลักษณะการทำงานของ ""

โปรดทราบว่ารหัสยังคงแทนที่สถานะการออกเป็นศูนย์ที่ได้รับจาก " gpg" (หรือgpg.program) หากผลลัพธ์ไม่ได้ระบุว่าลายเซ็นนั้นดีหรือคำนวณได้อย่างถูกต้อง แต่ทำด้วยคีย์ที่ไม่น่าเชื่อถือเพื่อตรวจจับกระดาษห่อหุ้มที่เขียนไม่ดีรอบ ๆ " gpg" ที่ผู้ใช้อาจให้เรา .

เราสามารถยกเว้น " U" การสนับสนุนที่ไม่น่าเชื่อถือออกจากรหัสทางเลือกนี้ได้ แต่จะทำให้การเปลี่ยนแปลงย้อนหลังสองรายการเข้ากันไม่ได้ในการคอมมิตเดียวดังนั้นตอนนี้เราควรหลีกเลี่ยงสิ่งนั้น
การเปลี่ยนแปลงติดตามผลสามารถทำได้หากต้องการ

คีย์จำเป็นเพื่อให้เชื่อถือ / ลงนามก่อนทำการเข้ารหัสใด ๆ

ในด้านความไว้วางใจมีความคืบหน้า:
ด้วย Git 2.26 (Q1 2020) gpg.minTrustLevelตัวแปรการกำหนดค่าได้รับการแนะนำเพื่อบอกรหัสเส้นทางการตรวจสอบลายเซ็นต่างๆถึงระดับความน่าเชื่อถือขั้นต่ำที่ต้องการ

ดูกระทำ 54887b4 (27 ธันวาคม 2019) โดยฮันส์เจอร์รี่ Illikainen (illikainen )
^{(รวมโดยJunio C Hamano - gitster-ในการกระทำ 11ad30b , 30 มกราคม 2020)}

gpg-interface: เพิ่ม minTrustLevel เป็นตัวเลือกการกำหนดค่า

^{ลงนามโดย: Hans Jerry Illikainen}

ก่อนหน้านี้ตรวจสอบลายเซ็นสำหรับการผสานและดึงการดำเนินงานการตรวจสอบถ้าคีย์มีความไว้วางใจในระดับของการอย่างใดอย่างหนึ่งTRUST_NEVERหรือใน TRUST_UNDEFINEDverify_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' (as in GOODSIG) และ ' U' (เช่นเดียวกับTRUST_NEVERหรือTRUST_UNDEFINED)ถือว่าทั้งคู่ประสบความสำเร็จ

ทั้งสองกรณีที่เป็นผลมาจาก ' U' มีความหมายพิเศษอยู่ในverify_merge_signature()(ที่ทำให้เกิดgitการdie()) และformat_commit_one()(ที่ได้รับผลกระทบการส่งออกของที่%G?ระบุรูปแบบ)

ฉันคิดว่ามันสมเหตุสมผลที่จะปรับโครงสร้างการประมวลผลของTRUST_ statusสายเพื่อให้ผู้ใช้สามารถกำหนดค่าระดับความน่าเชื่อถือขั้นต่ำที่บังคับใช้ทั่วโลกแทนที่จะให้แต่ละส่วนgit(เช่นการผสาน) ทำเอง (ยกเว้นช่วงเวลาผ่อนผันที่มีความเข้ากันได้ย้อนหลัง)

ฉันยังคิดว่ามันสมเหตุสมผลที่จะไม่เก็บระดับความไว้วางใจในสมาชิกโครงสร้างเดียวกันกับสถานะคีย์ / ลายเซ็น

แม้ว่าการมีอยู่ของTRUST_ statusรหัสจะบ่งบอกว่าลายเซ็นนั้นดี (ดูย่อหน้าแรกในตัวอย่างข้อมูลด้านบน) เท่าที่ฉันสามารถบอกได้ลำดับของบรรทัดสถานะจาก GPG ไม่ได้กำหนดไว้อย่างชัดเจน ดังนั้นจึงดูเหมือนเป็นไปได้ที่ระดับความน่าเชื่อถือสามารถถูกเขียนทับด้วยสถานะคีย์ / ลายเซ็นหากพวกเขาถูกเก็บไว้ในสมาชิกเดียวกันของ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()อีกวิธีหนึ่งที่จะได้รับเพียงแค่วางความต้องการความไว้วางใจระดับใน

สิ่งนี้จะทำให้พฤติกรรมสอดคล้องกับส่วนอื่น ๆ ของคอมไพล์ที่ดำเนินการตรวจสอบลายเซ็น

อย่างไรก็ตามการกำหนดระดับความน่าเชื่อถือขั้นต่ำสำหรับการลงนามคีย์ดูเหมือนจะมีกรณีการใช้งานจริง

ยกตัวอย่างเช่นการสร้างระบบที่ใช้โดยโครงการ Qubes OS ปัจจุบันแยกวิเคราะห์การส่งออกดิบจากการตรวจสอบแท็กเพื่อยืนยันความไว้วางใจในระดับต่ำสุดสำหรับปุ่มที่ใช้ในการเข้าสู่ระบบแท็กคอมไพล์

git config gpgหน้าคนในขณะนี้รวมถึง:

gpg.minTrustLevel:

ระบุระดับความเชื่อถือขั้นต่ำสำหรับการตรวจสอบลายเซ็น
หากไม่ได้ตั้งค่าตัวเลือกนี้การตรวจสอบลายเซ็นสำหรับการดำเนินการผสานต้องใช้คีย์ที่marginalเชื่อถือได้เป็นอย่างน้อย
การดำเนินการอื่น ๆ ที่ดำเนินการตรวจสอบลายเซ็นจำเป็นต้องมีคีย์ที่undefinedเชื่อถือได้เป็นอย่างน้อย
การตั้งค่าตัวเลือกนี้จะแทนที่ระดับความเชื่อถือที่จำเป็นสำหรับการดำเนินการทั้งหมด ค่าที่รองรับตามลำดับความสำคัญที่เพิ่มขึ้น:

• undefined
• never
• marginal
• fully
• ultimate

ด้วยGit 2.26 (Q1 2020) " git show" และอื่น ๆ ให้ชื่ออ็อบเจ็กต์ในรูปแบบดิบในเอาต์พุตข้อผิดพลาดซึ่งได้รับการแก้ไขเพื่อให้เป็นเลขฐานสิบหก

show_one_mergetag: พิมพ์ที่ไม่ใช่พาเรนต์ในรูปแบบฐานสิบหก

เมื่อ mergetag ตั้งชื่อไม่ใช่พาเรนต์ซึ่งอาจเกิดขึ้นหลังจากการโคลนตื้นก่อนหน้านี้แฮชจะถูกพิมพ์เป็นข้อมูลดิบ
พิมพ์ในรูปฐานสิบหกแทน

ทดสอบด้วยgit -C shallow log --graph --show-signature -n1 plain-shallowafter agit clone --depth 1 --no-local . shallow

ด้วย Git 2.27 (Q2 2020) โค้ดสำหรับเชื่อมต่อกับ GnuPG ได้รับการปรับโครงสร้างใหม่

ดูกระทำ 6794898 , กระทำ f1e3df3 (4 มีนาคม 2020) โดยฮันส์เจอร์รี่ Illikainen (illikainen )
^{(ผสานโดยJunio ​​C Hamano - gitster-ในการกระทำ fa82be9 , 27 มี.ค. 2020)}

gpg-interface: ชอบcheck_signature()การตรวจสอบ GPG

^{ลงนามโดย: Hans Jerry Illikainen}

สิ่งนี้ส่งผลกระทบต่อการใช้verify_signed_buffer()ภายนอกgpg-interface.cเพื่อใช้check_signature()แทน

นอกจากนี้ยังเปลี่ยนverify_signed_buffer()เป็นฟังก์ชั่น file-local เนื่องจากตอนนี้เรียกใช้ภายในโดยcheck_signature().

ก่อนหน้านี้มีสองหน้าที่ขอบเขตทั่วโลกใช้ในส่วนต่างๆของ Git เพื่อดำเนินการตรวจสอบลายเซ็น GPG: และ verify_signed_buffer()check_signature()

ตอนนี้check_signature()ใช้เท่านั้น

verify_signed_buffer()ฟังก์ชั่นไม่ได้ป้องกันลายเซ็นที่ซ้ำกันตามที่อธิบายMichałGórny

แต่จะทำให้มั่นใจได้ว่ารหัสทางออกที่ไม่ผิดพลาดจาก GPG และการมีอยู่ของGOODSIGฟิลด์สถานะอย่างน้อยหนึ่งฟิลด์

สิ่งนี้ตรงกันข้ามกับcheck_signature()ที่ส่งกลับข้อผิดพลาดหากพบลายเซ็นมากกว่าหนึ่งลายเซ็น

ระดับการตรวจสอบที่ต่ำกว่าทำให้การใช้งานverify_signed_buffer()มีปัญหาหากผู้โทรไม่แยกวิเคราะห์และตรวจสอบส่วนต่างๆของข้อความสถานะ GPG ด้วยตนเอง

และการประมวลผลข้อความเหล่านี้ดูเหมือนว่างานที่ควรจะสงวนไว้ไปด้วยฟังก์ชั่นgpg-interface.ccheck_signature()

นอกจากนี้การใช้งานverify_signed_buffer()ทำให้ยากที่จะแนะนำฟังก์ชันใหม่ที่อาศัยเนื้อหาของบรรทัดสถานะ GPG

gpg-interface.cตอนนี้การดำเนินงานทั้งหมดที่จะใช้ร่วมกันจุดรายการเดียวที่จะตรวจสอบลายเซ็น

นี้จะทำให้มันง่ายขึ้นเพื่อเผยแพร่การเปลี่ยนแปลงหรือการทำงานเพิ่มเติมใน GPG ตรวจสอบลายเซ็นกับทุกส่วนของ Git โดยไม่ต้องแปลกขอบกรณีที่ไม่ได้ดำเนินการในระดับเดียวกับการตรวจสอบ

การตรวจสอบโค้ดคร่าวๆแสดงให้เห็นว่าไม่มีวิธีการโดยตรงดังกล่าว

การทดสอบทั้งหมดในแหล่ง git อาศัยgrepping ผลลัพธ์ของgit show(ดูt / t7510-signed-commit.shสำหรับการทดสอบ)

คุณสามารถปรับแต่งผลลัพธ์โดยใช้สิ่งที่ต้องการ--pretty "%H %G?%"เพื่อให้ง่ายต่อการแยกวิเคราะห์

ดูเหมือนว่าคุณสามารถขอgit mergeให้ยืนยันลายเซ็นได้ แต่อีกครั้งการทดสอบจะขึ้นอยู่กับgrep(ดูt / t7612-merge-verify-signatures.sh ) ดูเหมือนว่าลายเซ็นที่ไม่ถูกต้องจะทำให้git mergeออกด้วยลายเซ็นที่ไม่ถูกต้องดังนั้นวันนี้คุณอาจแฮ็คสิ่งนี้ได้โดยทำการทดสอบรวมที่ใดที่หนึ่งแล้วโยนออกไป แต่ดูเหมือนจะแย่กว่าแค่เรียก grep