โปรแกรมติดตั้ง Windows ของ ImageMagick จะไม่มีการลงนามอีกต่อไป
(github.com/ImageMagick)- ImageMagick แจ้งว่า ใบรับรองการลงนามโค้ด ที่ใช้อยู่จะหมดอายุในวันที่ 28 ตุลาคม 2023 และจะไม่ได้รับใบรับรองที่ LeaderSSL สนับสนุนอีกต่อไป
- ตั้งแต่เดือนมิถุนายน 2023 เป็นต้นมา CA/B Forum กำหนดให้ต้องเก็บ private key สำหรับการลงนามโค้ดแบบ OV ไว้ในอุปกรณ์ที่ได้รับการรับรอง FIPS 140-2 Level 2 หรือ Common Criteria Level EAL4+ ทำให้ไม่สามารถ export private key ไปใช้ใน GitHub Actions ได้อีก
- ผลกระทบไม่ได้จำกัดอยู่แค่โปรแกรมติดตั้ง
.exeเท่านั้น แต่ครอบคลุมถึง ไบนารีทั้งหมด ที่เคยลงนามด้วยใบรับรองการลงนามโค้ด - ในการอภิปรายมีการพูดถึงทางเลือกอย่างใบรับรองของ Digicert ราคา 629 ดอลลาร์ต่อปี, SignPath, Azure Key Vault กับ AzureSignTool, Azure Code Signing และการลงนามเอง โดยบางทางเลือกมีข้อจำกัด เช่น การเชื่อมกับ GitHub Actions หรือข้อกำหนดให้ใช้ AppVeyor
- เมื่อวันที่ 6 พฤศจิกายน 2023 ImageMagick ตัดสินใจใช้ Azure Code Signing และทำให้สามารถกลับมาลงนามไบนารีได้อีกครั้ง
ปัญหาใบรับรองหมดอายุและการหยุดลงนาม
- ผู้ดูแล ImageMagick แจ้งว่า ใบรับรองการลงนามโค้ด ที่ใช้อยู่ในขณะนั้นจะหมดอายุในวันที่ 28 ตุลาคม 2023
- ตลอดหลายปีที่ผ่านมา LeaderSSL เป็นผู้สนับสนุนใบรับรองการลงนามโค้ด แต่ไม่สามารถสนับสนุนต่อได้อีก
- ตั้งแต่เดือนมิถุนายน 2023 เป็นต้นมา ข้อกำหนดของ CA/B Forum เปลี่ยนไป โดย private key สำหรับการลงนามโค้ดแบบ OV ต้องถูกเก็บไว้ในอย่างใดอย่างหนึ่งต่อไปนี้
- อุปกรณ์ที่ได้รับการรับรอง FIPS 140-2 Level 2
- อุปกรณ์ที่ได้รับการรับรอง Common Criteria Level EAL4+
- ข้อกำหนดนี้ทำให้ ImageMagick ไม่สามารถใช้วิธีเดิมที่ export ใบรับรองการลงนามโค้ดและ private key ไปใช้ใน GitHub Actions ต่อไปได้
ทางเลือกที่ต้องใช้และค่าใช้จ่าย
- ผู้ดูแลเสนอทางเลือกใหม่ไว้ 2 แบบ
- ใช้ self-hosted GitHub agent และ hardware token
- ใช้ โซลูชันการลงนามบนคลาวด์ ที่เชื่อมกับ GitHub ได้
- แนวทางที่ต้องการคือโซลูชันบนคลาวด์ที่เชื่อมกับ GitHub
- ในเวลานั้น ผู้ดูแลระบุว่า Digicert ดูเหมือนจะเป็นตัวเลือกเดียว โดยใบรับรองการลงนามโค้ดของ Digicert มีราคา 629 ดอลลาร์ ต่อ 1 ปี และยังไม่รวมภาษี
- หากมีองค์กรใดต้องการโปรแกรมติดตั้งที่มีการลงนาม ก็ขอให้ช่วยสนับสนุนใบรับรองการลงนามโค้ด
ขอบเขตของผลกระทบ
- มีผู้ร่วมอภิปรายคนหนึ่งถามว่าผลกระทบนี้มีผลเฉพาะกับโปรแกรมติดตั้ง
.exeหรือรวมถึงไบนารี Win32 ทั้งหมด เช่นmagick.exeใน portable zip ที่จะไม่ถูกลงนามด้วย - ผู้ดูแลตอบว่า ไบนารีทั้งหมด ที่เคยลงนามด้วยใบรับรองการลงนามโค้ดได้รับผลกระทบ
ทางเลือกที่ถูกหารือ
-
SignPath
- มีผู้ร่วมอภิปรายแนะนำ SignPath และผู้ดูแลตอบว่าไม่เคยรู้จักบริษัทนี้มาก่อน แต่ก็น่าจะเป็นทางเลือกได้
- ผู้ร่วมอภิปรายอีกรายเล่าว่าใช้ SignPath กับโครงการ OSS มานานกว่า 2 ปี และได้รับการตอบคำถามเป็นอย่างดีเสมอ
- ผู้ร่วมอภิปรายรายดังกล่าวเสริมว่า เท่าที่ทราบ เนื่องจากวิธีตรวจสอบแหล่งที่มาของ SignPath การสร้างไบนารีหรือโปรแกรมติดตั้งที่มีการลงนามต้องใช้ AppVeyor และโปรแกรมติดตั้งต้องเป็นรูปแบบ
.MSI - ผู้ร่วมอภิปรายจากฝั่ง SignPath อธิบายว่าใบรับรองฟรีมีข้อจำกัดบางส่วน
- ใบรับรองฟรีที่ออกให้กับ “SignPath Foundation” ต้องใช้บิลด์ที่โปร่งใสและตรวจสอบได้ ซึ่งในเวลานั้นหมายถึง AppVeyor
- คอนเนกเตอร์สำหรับ GitHub Actions จะเปิดให้ใช้ในเร็ว ๆ นี้
- รูปแบบมาตรฐานอย่าง MSI, MSIX และ AppX มีข้อดี แต่ก็สามารถจัดการโปรแกรมติดตั้งแบบอื่นได้เช่นกัน
- เนื่องจาก ImageMagick มี LLC ที่จดทะเบียนอยู่แล้ว จึงสามารถขอใบรับรองในนาม ImageMagick ได้โดยไม่มีข้อจำกัด และ SignPath เสนอว่าจะสนับสนุนให้ในปีแรก
-
Azure Key Vault และ AzureSignTool
- ผู้ร่วมอภิปรายคนหนึ่งแชร์ว่าใช้ใบรับรอง EV code signing ที่ออกโดย GlobalSign เก็บไว้ใน Azure Key Vault และใช้ AzureSignTool เพื่อลงนามไฟล์จาก GitHub Actions
- ผู้ดูแลตอบว่าวิธีนี้ดูเหมือนจะเป็นตัวเลือกที่ถูกกว่า และบอกว่าเพิ่งมีคนแนะนำ dotnet/sign ที่ใช้
AzureSignToolเมื่อวันก่อน - ผู้ร่วมอภิปรายอีกรายแชร์บทความเกี่ยวกับการลงนามโปรแกรมติดตั้ง Windows ด้วยใบรับรอง EV โดยใช้ GlobalSign ร่วมกับ Azure Key Vault
- มีผู้ร่วมอภิปรายคนหนึ่งบอกว่า Azure Key Vault รองรับสิ่งนี้ และแม้จะลงนามบิลด์วันละหลายครั้ง ค่าใช้จ่ายก็อยู่ในระดับไม่กี่เซนต์
- ต่อมาผู้ร่วมอภิปรายอีกรายเสริมว่า หลังจากใบรับรองหมดอายุในเดือนมกราคม 2024 เขาก็พบปัญหาเดียวกัน โดยใบรับรองใหม่ต้องถูกออกในอุปกรณ์และไม่สามารถย้ายไป Azure Key Vault ได้
-
Azure Code Signing
- ผู้ร่วมอภิปรายคนหนึ่งบอกว่าย้ายไปใช้ Azure Code Signing แล้ว และจะลองติดต่อ Microsoft กับทีมที่เกี่ยวข้องให้
- ผู้ดูแลตอบว่าได้ส่งอีเมลถึง AzureCodeSigningTAP โดยตรงแล้ว
- ผู้ร่วมอภิปรายที่ระบุว่าตนเป็นวิศวกร Azure Code Signing บอกว่ารองรับ GitHub Actions และให้ติดต่อมาได้หากจำเป็น
-
การลงนามเอง
- มีผู้ร่วมอภิปรายคนหนึ่งถามว่าเคยพิจารณาวิธีลงนามไบนารีด้วยตนเอง แล้วให้ผู้ใช้ติดตั้งใบรับรองสาธารณะเองหรือไม่
- ผู้ดูแลตอบว่ายังไม่ได้พิจารณา และกำลังตรวจสอบตัวเลือกต่าง ๆ ที่ถูกเสนอในวงสนทนา
การตัดสินใจสุดท้าย
- เมื่อวันที่ 6 พฤศจิกายน 2023 ผู้ดูแลขอบคุณสำหรับตัวเลือกต่าง ๆ ที่เสนอมา และประกาศว่าตัดสินใจใช้ Azure Code Signing
- การตัดสินใจนี้ทำให้ ImageMagick สามารถกลับมาลงนามไบนารีได้อีกครั้ง
- มีการระบุว่าขั้นตอนการตั้งค่าได้สรุปไว้ในโพสต์ของอีก repository หนึ่งคือ ImageMagick now uses Azure Code Signing
1 ความคิดเห็น
ความเห็นจาก Hacker News
ผมทำวิดีโอเพลเยอร์โอเพนซอร์สสำหรับโค้ชอีสปอร์ตแจกฟรี แต่ก็โดนบ่นตลอดว่าตอนติดตั้งครั้งแรกต้องกดข้ามคำเตือน เลยเข้าใจความเจ็บปวดนี้ดี
ผมพอจะจ่ายค่ารับรองได้ แต่ก็ไม่อยากต้องควักเงินเพิ่มให้โปรเจ็กต์ที่ผมใช้เวลาไปแล้วเพื่อแจกฟรี
ถ้ามีบริการแบบ Let's Encrypt สำหรับซอฟต์แวร์โอเพนซอร์สก็คงดี แต่ในมุมของ Microsoft หรือ Apple มันน่าจะขัดกับผลประโยชน์หลัก เพราะอาจทำให้คนหลุดออกจากสวนที่มีกำแพงล้อมรอบอย่างแอปสโตร์
ผมทำซอฟต์แวร์มาเกือบ 25 ปีแล้ว และก็รู้สึกขมขื่นพอสมควรที่เห็นว่าการเป็นเจ้าของคอมพิวเตอร์ของตัวเองค่อย ๆ ลดลงภายใต้ชื่อของ “ความปลอดภัย”
https://www.vodon.gg/
คำตอบทั่วไปคือ ใบรับรองสำหรับเซ็นโค้ดมีเป้าหมายเพื่อเป็นหลักฐานยืนยันตัวตนทางกฎหมาย เพื่อให้สามารถลงโทษคนที่ปล่อยมัลแวร์ได้ในโลกออฟไลน์ หรือเปิดใช้นโยบายที่อนุญาตให้ติดตั้งเฉพาะซอฟต์แวร์จากรายชื่อผู้เผยแพร่ที่กำหนด
ขณะที่ใบรับรองแบบตรวจสอบโดเมนสำหรับ HTTPS มีเป้าหมายเพื่อพิสูจน์การควบคุมชื่อ DNS ซึ่งสามารถตรวจสอบได้ด้วยวิธีทางเทคนิคแบบอัตโนมัติ และไม่จำเป็นต้องเชื่อมโยงกับตัวตนออฟไลน์เสมอไป
ใบรับรอง Let's Encrypt ยืนยันได้เพียงว่ากุญแจหนึ่งดูเหมือนจะถูกควบคุมโดยคนที่ควบคุมชื่อ DNS เฉพาะนั้น แต่ใบรับรองเซ็นโค้ดพยายามยืนยันให้ถึงขั้นว่าดูเหมือนจะถูกควบคุมโดยตัวแทนของนิติบุคคลที่เฉพาะเจาะจงในเขตอำนาจศาลที่เฉพาะเจาะจง ซึ่งมีต้นทุนในการตรวจสอบให้ใช้งานได้จริงสูงกว่ามาก
วันหนึ่งรัฐบาลอาจมีวิธีทำสิ่งนี้ให้เป็นอัตโนมัติได้ แต่สิ่งที่ใบรับรองทั้งสองประเภทพิสูจน์และวิธีตรวจสอบนั้นแตกต่างกันมาก
มีการถกเถียงที่เกี่ยวข้องต่อยาวกว่านี้แล้วที่ https://news.ycombinator.com/item?id=38056024
ถ้าผู้ใช้แคร์เรื่องนี้จริง ก็น่าจะยินดีช่วยกันออกค่าใช้จ่าย และถ้าไม่ ก็ไม่น่าถือว่าการไม่มีลายเซ็นเป็นปัญหา
ดูเหมือนว่าถ้ายอดดาวน์โหลดมากพอ คำเตือนนี้จะหายไป
ถ้าใช้ Mac ก็ต้องกังวลเรื่องพวกนี้น้อยลง
ปัญหาไม่ได้มีแค่เรื่องค่าใช้จ่าย
ผมจัดการการเซ็นผ่านเวิร์กโฟลว์รีลีสอัตโนมัติมาตลอด
https://github.com/technion/rustypwneddownloader/blob/main/....
ภายใต้กฎใหม่ ผมใช้เวิร์กโฟลว์นี้ไม่ได้แล้ว และก็ยากจะเชื่อว่าการย้ายบิลด์ไปที่เดสก์ท็อปของตัวเองเพื่อใช้ฮาร์ดแวร์คีย์สำหรับการเซ็น แล้วอัปโหลดด้วยวิธีที่ไม่อัตโนมัติและไม่โปร่งใส จะถือเป็นการปรับปรุงด้านความปลอดภัย
อย่างแรก คีย์ส่วนตัวที่เก็บเป็นไฟล์สามารถถูกขโมยไปแบบเงียบ ๆ ได้ และเมื่อเป็นแบบนั้นสิ่งที่ทำได้ก็เหลือแค่เพิกถอน
นี่คือเหตุผลหลักของข้อกำหนด HSM และคนทำมัลแวร์ก็ทำแบบนี้มาสักพักแล้ว อีกทั้งการเพิกถอนก็ยากและมีค่าใช้จ่ายสูงด้วยหลายเหตุผล
HSM เองก็อาจถูกขโมยได้ แต่คนร้ายต้องบุกเข้าบ้านหรือออฟฟิศแล้วขนของออกไป ดังนั้นมีโอกาสสูงที่จะรู้ตัว
ข้อมูลยืนยันตัวตนสำหรับใช้ HSM ก็อาจถูกขโมยได้เช่นกัน แต่สามารถเปลี่ยนได้ง่ายและเร็วกว่า ดังนั้นถ้ารู้ว่า PIN ถูกดักด้วยคีย์ล็อกเกอร์ หลังจากกู้คืนจากการถูกเจาะแล้วก็แค่เปลี่ยน PIN โดยไม่จำเป็นต้องเพิกถอนใบรับรอง
อย่างที่สอง การเซ็นแบบอัตโนมัติใน CI อาจเสี่ยงจริง
ใครก็ตามที่พุชโค้ดเข้า CI ได้ สามารถให้ระบบเซ็นโค้ดในชื่อคุณได้ และคุณอาจไม่รู้ตัวด้วยซ้ำ
เพราะคีย์ออนไลน์อยู่ตลอด ถ้า CI ถูกแฮ็กก็จบเลย และถึงไม่ถูกแฮ็ก CI ก็รันโค้ดตามอำเภอใจจำนวนมากโดยไม่ได้ถูกเฝ้าดูอย่างใกล้ชิด ดังนั้นทุกคนที่สามารถพุชโค้ดเข้าไปได้ก็กลายเป็นจุดอ่อน
ถ้าเซ็นจากเครื่องโลคัล คุณสามารถเก็บคีย์ให้ออฟไลน์จริง ๆ จนถึงช่วงรีลีส และยังทำการยืนยันตัวตนสองขั้นตอนได้ด้วยองค์ประกอบการครอบครองอย่างตัวคีย์ และองค์ประกอบความรู้ความจำอย่างข้อมูลรับรอง จึงค่อนข้างปลอดภัย
บิลด์พัฒนากลางคืน เครื่องมือภายใน และไบนารีชั่วคราวที่ไม่ควรออกไปภายนอก ก็เซ็นเองฟรี ๆ ได้
ผมเก็บใบรับรอง OV .pfx ไว้ใน GitHub Actions secrets และใช้งานแบบเดียวกัน
ใบรับรองของผมจะหมดอายุในเดือนพฤศจิกายน 2024 และยังตัดสินใจไม่ได้ว่าจะทำอย่างไรต่อ
แค่การขอใบรับรองในฐานะนักพัฒนาเดี่ยวที่ไม่ใช่บริษัทก็ยากมากพออยู่แล้ว
ถึงอย่างนั้น สุดท้ายมันก็น่าจะเป็นเรื่องเงิน
ถ้าใช้คลาวด์โฮสติ้ง HSM ปีละ $629 ตามที่บทความต้นฉบับบอก ก็ยังทำได้ และเมื่อจ่ายค่านั้น คุณก็ยังสั่งงานจาก GitHub Actions ด้วยคำสั่งอย่าง signtool หรือ Set-AuthenticodeSignature ที่ใช้อยู่ตอนนี้ได้: https://docs.digicert.com/en/software-trust-manager/ci-cd-in...
ใช้เครื่อง SFF/Atom PC เล็ก ๆ สักเครื่องราคาประมาณ 100 ดอลลาร์แล้วเสียบฮาร์ดแวร์คีย์เข้าไป
สิ่งที่เปลี่ยนก็มีแค่ขั้นตอนการเซ็นย้ายจากคลาวด์มาที่ตัวรันโลคัล
ในแง่ความปลอดภัย ผมก็ยังไม่แน่ใจว่าควรมองว่าเป็นการปรับปรุงหรือไม่
น่าแปลกที่โปรเจ็กต์สำคัญและมีการใช้งานอย่างแพร่หลายอย่าง ImageMagick กลับหาเงินได้ไม่ถึง $629 สำหรับสิ่งจำเป็นอย่างการเซ็นซอฟต์แวร์
นี่เป็นตัวอย่างชัดเจนว่าอุตสาหกรรมเทคโนโลยีไม่สามารถสนับสนุนทางการเงินให้โปรเจ็กต์โอเพนซอร์สที่ตัวเองพึ่งพาอย่างมากได้อย่างเหมาะสม
แม้จะสร้างคุณค่าอย่างมหาศาล แต่โปรเจ็กต์แบบนี้ก็มักไม่สามารถดึงมูลค่ากลับคืนมาได้มากพอจะทำให้ยั่งยืน
เป็นเครื่องเตือนใจที่ตรงไปตรงมาว่าจำเป็นต้องมีการเปลี่ยนแปลงครั้งใหญ่ในวิธีที่เราปฏิบัติและประเมินคุณค่าของการมีส่วนร่วมในโอเพนซอร์ส
ประเด็นสำคัญคือมันเป็นเรื่องความปลอดภัยจริง ๆ หรือเป็นเรื่องของการตะโกนคำว่า “ความปลอดภัย” เพื่อผลักดัน ตลาดที่ต้องจ่ายเงินถึงจะเข้าร่วมได้ กันแน่
ผมกลับรู้สึกว่ามันควรจะเป็นอีกทางมากกว่า
$629 ไม่ใช่เงินเล็กน้อย
นี่คือสิ่งที่ Microsoft สร้างขึ้นมาเองในระบบนิเวศของ Windows
ไม่ใช่การจ่ายค่าเช่าให้ Microsoft หรือพาร์ตเนอร์ของมัน
โปรแกรมแก้ไขข้อความบนเดสก์ท็อปของผม KeenWrite ใช้ Wine, rcedit-x64.exe, osslsigncode และเชลล์สคริปต์ในการเซ็นไบนารีของ Windows
ก่อนอื่น rcedit-x64.exe จะใส่ข้อมูลระบุตัวตนลงในไบนารี
https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/installe...
จากนั้น osslsigncode จะนำใบรับรองมาใช้
https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/scripts/...
อย่างที่พูดไปก่อนหน้านี้ การที่โปรเจ็กต์โอเพนซอร์สที่มีรายได้ 0 ดอลลาร์ต้องจ่ายเงินเพื่อแจกจ่ายบน Windows คือการที่ความเป็นเจ้าของคอมพิวเตอร์ของผมลดลง
ตอนนี้ต้องเป็นแบบ ใช้ HSM
ผมเจอนรกกับการเซ็นแอปทั้งบน Windows และ macOS และมันก็ยิ่งแย่ลงเรื่อย ๆ
อย่างแรกเลย เรื่องนี้ทำให้อยากให้ทุกอย่างเป็น เว็บแอป ไปหมด
เบราว์เซอร์ให้ประสบการณ์ที่ดีกว่ามากในหลายด้าน และเป็นประสบการณ์ที่รวมความปลอดภัยไว้อย่างดี ขณะที่ระบบปฏิบัติการอายุ 25 ปีเหล่านี้ให้ความรู้สึกเหมือนเพิ่งมาแปะเรื่องความปลอดภัยทีหลัง
คงไม่มีใครใน Apple แคร์หรอก แต่ถ้านี่กลายเป็นรอยร้าวที่ทำลายการผูกขาดฮาร์ดแวร์และซอฟต์แวร์ของพวกเขาได้ก็คงน่าขำดี
อย่างที่สอง ผมสงสัยว่าทำไมถึงไม่มีบุคคลที่สามให้บริการเซ็นแบบนี้ได้
ในเชิงเทคนิค จำนวนแอปที่ผมจะเซ็นได้ก็ไม่น่ามีข้อจำกัดไม่ใช่หรือ?
และในมุมผู้ใช้ ผมก็ไม่เห็นว่าทำไมจะเป็นปัญหาหากใบรับรองไม่ได้เซ็นด้วยชื่อของผม แต่เป็นชื่อ ABC Corp ที่ระบบปฏิบัติการเชื่อถือ
อาจเพิกถอนบางส่วนในสายโซ่ความเชื่อถือได้ แต่ในทางเทคนิคมันก็ดูเป็นไปได้ และผมก็สงสัยว่ามันถูกห้ามไว้อย่างชัดเจนใน EULA ที่ผมเคยกดตกลงแบบมึน ๆ ตรงไหนหรือเปล่า
ถึงอย่างนั้นเราก็พอใจกับผลลัพธ์มาก และดูเหมือนผู้ใช้ก็เช่นกัน
ที่ตลกคือไม่นานมานี้มีคนหนึ่งแนะนำให้ผมลองใช้มัน ทั้งที่ไม่รู้ว่าผมเป็นผู้เขียนหลัก เลยค่อนข้างตกใจทีเดียว
ในสถานการณ์นี้คือจะเซ็นให้ทุกอย่างแบบหลับหูหลับตาเลยหรือ? ถ้าใช่ก็คงไม่ดีแน่
อีกทางเลือกคือกระบวนการตรวจสอบและออดิทยาวนาน ซึ่งถ้ามีอะไรหลุดรอดไปได้ คนที่เซ็นก็ยังโดนผลกระทบอยู่ดี
ถ้าไม่ใช่ไดรเวอร์อุปกรณ์ เราก็กำลังเข้าใกล้จุดที่สามารถรีคอมไพล์ให้ไปรันฝั่งไคลเอนต์ในเบราว์เซอร์ได้แล้ว
ที่บริษัทเราเพิ่งเจอปัญหาเดียวกันนี้ และเพิ่งมารู้ว่าข้อกำหนดเปลี่ยนไปก็ตอนที่ต่ออายุใบรับรองกับผู้ให้บริการเดิมไม่ได้
ตอนนี้มีข้อมูลน้อยจนน่าตกใจเกี่ยวกับวิธีทำ Windows code signing
เราไม่อยากใช้อุปกรณ์จริง และสำหรับทีมที่ทำงานระยะไกลทั้งหมดมันก็ไม่สมเหตุสมผล
สุดท้ายเลยเลือกใช้ Azure KeyVault ร่วมกับ Digicert
ผมไม่ชอบ Comodo หรือก็คือ Sectigo
มีข้อมูลน้อยมากว่าทำอย่างไรให้ชุดนี้ใช้งานได้จริง และต้องจ่ายไปประมาณ $600 ก่อนจะได้ลองด้วยซ้ำว่ามันเวิร์กหรือไม่
แต่พอตั้งค่าเสร็จแล้วมันก็ทำงานได้ดี
การตั้งค่าใหม่ที่เซ็นผ่าน Azure ปลอดภัยกว่าการเก็บ private key ไว้ในระบบ CI
แต่ผมไม่เคยคิดเลยว่าการเซ็นแอปบน Windows จะยากกว่าการเซ็นบน macOS หรือ iOS
ภารกิจสำเร็จ
อย่างที่บอก ข้อมูลมีน้อย และน่าจะเป็นประโยชน์กับหลายคนรวมถึงผมด้วย
ผมสงสัยว่ามีใครเคยใช้ SignPath(https://signpath.org) ที่มีคนพูดถึงในคำตอบหนึ่งบ้างไหม
บนเว็บไซต์เขียนไว้ว่า “SignPath Foundation provides reliable code signing for Open Source projects.”
ถ้าเป็นบริการที่ถูกต้องน่าเชื่อถือ ก็น่าจะเป็นอีกตัวเลือกที่มีประโยชน์
ตอนนี้ “มูลนิธิ” ยังดำเนินการโดยบริษัท SignPath แต่ก็มีการบอกว่าในอนาคตหวังให้มูลนิธิขยายตัวจนเป็นองค์กรอิสระที่ชุมชนดูแลได้
ชวนให้คิดว่า “Developers, developers, developers!” หายไปไหนแล้ว
สิ่งที่เห็นร่วมกันในบริษัทเทคโนโลยีขนาดใหญ่คือ ตอนแรกดูดี แต่พอผ่านไปไม่กี่ปีก็เริ่มเสื่อมทรามแทรกซึมเข้ามา และถ้าอยู่มานานพอ สุดท้ายก็กลายเป็นปรสิต
ถ้าเป็นบริษัทขนาด Microsoft ก็คงเป็นไปไม่ได้ที่จะไม่มีวิธีทำให้โลกเสรีและโอเพนซอร์สที่พวกเขาบอกว่าสนับสนุนนั้น สามารถแจกจ่ายซอฟต์แวร์บนแพลตฟอร์มของตนได้โดยไม่มีความยุ่งยากหรือค่าใช้จ่าย
ความฝืดแบบนี้ภายใต้ชื่อของความปลอดภัย ก็บังเอิญช่วยเพิ่มรายได้อยู่เสมอ
อยากให้ลดต้นทุนของใบรับรองลายเซ็นโดยรวมลง
แค่ประมาณ 10 ดอลลาร์ ก็น่าจะพอ
สำหรับซอฟต์แวร์เฉพาะทางที่มีคนใช้น้อยมาก ตอนนี้ยังไม่มีทางอธิบายความคุ้มค่าของค่าใช้จ่ายนี้ได้
เหตุผลเดียวที่พอนึกออกว่าทำไมต้องแพงขนาดนี้ ก็คือมันต้องเป็นจำนวนเงินที่มากพอให้เจ้าของบัตรที่ถูกขโมยตัวจริงสังเกตเห็น
ซึ่งในตัวมันเองก็อาจนับเป็นการยืนยันตัวผู้จัดทำได้รูปแบบหนึ่ง
ถ้าอย่างนั้นก็น่าจะคืนเงินบางส่วนหรือทั้งหมดหลังผ่านไป 3 เดือนได้ไม่ใช่หรือ
ต่อให้มีจุดประสงค์เพื่อการยืนยัน ก็แทบไม่เห็นเหตุผลว่าทำไมต้องเก็บเงินทุกปี และสุดท้ายมันก็ดูเหมือนการแสวงหาค่าเช่า
เท่าที่จำได้ Store เป็นแบบ จ่ายครั้งเดียว $19 ไม่ใช่ค่าใช้จ่ายแบบต่อเนื่องหรือรายปี
เพราะฉะนั้นปัญหานี้จึงเกิดเฉพาะเวลาจะแจกจ่ายนอก Store เท่านั้น
เหตุผลที่ใบรับรองมีราคาแพง เป็นเพราะรัฐบาลยังไม่เป็นดิจิทัลและจัดการคริปโตกราฟีได้ไม่ดีพอ จึงต้องใช้แรงงานคนจำนวนมากในการเชื่อมโยงการถือครอง private key เข้ากับการถือครองตัวตนทางกฎหมาย
หน่วยงานออกใบรับรองต้องไปค้นข้อมูลการจดทะเบียนจากเว็บไซต์ของแต่ละประเทศ ซึ่งหลายแห่งไม่มี API และยังต้องโทรศัพท์ ตรวจสอบสแกนพาสปอร์ต และทำงานลักษณะนี้อีกมาก
ทั้งหมดนี้ใช้แรงงานเข้มข้นจึงทำให้แพง
ถ้ารัฐมี public key infrastructure ของตัวเองและออก private key ให้พร้อมตอนจดทะเบียนบริษัท หรือถ้าในพาสปอร์ตมี private key สำหรับเซ็นเอกสาร ก็อาจทำให้ถูกลงได้มาก
น่าเสียดายที่เรื่องนี้แทบไม่มีความคืบหน้ามานานแล้ว และแม้แต่บางประเทศที่เคยทดลองใช้ public key infrastructure ระดับชาติก็เลิกไปเกือบหมด
สหรัฐฯ เองก็ไม่เคยพยายามทำ public key infrastructure ภาครัฐขนาดใหญ่นอกกระทรวงกลาโหม ดังนั้นบริษัทซอฟต์แวร์ในสหรัฐฯ จึงแทบไม่รู้สึกจำเป็นต้องรองรับสมาร์ตการ์ดให้ดีนัก
ระบบปฏิบัติการกระแสหลักก็ไม่มีการรองรับที่แข็งแรง และมาตรฐานก็ยังไม่เพียงพอ
ยังไม่นับภาระด้านการปฏิบัติการระดับสูงที่ Microsoft ในฐานะผู้บริโภคใบรับรอง และ CA/Browser Forum กำหนดไว้กับหน่วยงานออกใบรับรอง
เรื่องนี้ก็มีต้นทุนเช่นกัน
ค่าธรรมเนียมรายปีมีไว้เพื่อเฉลี่ยต้นทุนออกไปตามเวลา
หน่วยงานออกใบรับรองมีต้นทุนสูงกว่าค่าธรรมเนียม 1 ปีเสียอีกในตอนออกใบรับรองครั้งแรก แต่ถ้าสมมติว่าผู้ใช้จะใช้งานหลายปี พวกเขาก็จะผ่านจุดคุ้มทุนและทำกำไรเล็กน้อยได้
https://www.gnu.org/philosophy/right-to-read.en.html
ยิ่งมีอายุมากขึ้น ก็ยิ่งรู้สึกว่า RMS คือแคสซานดราแห่งยุคสมัยใหม่