
shim की समीक्षाएँ
This repo is for review of requests for signing shim. To create a request for review:
Note that we really only have experience with using GRUB2 or systemd-boot on Linux, so asking us to endorse anything else for signing is going to require some convincing on your part.
As of 20 October 2025, shims sent to Microsoft will be signed with the 2011 and 2023 keys. For each shim you submit, you will receive two copies back, each signed by a different key. Here is the latest information from Microsoft: https://techcommunity.microsoft.com/blog/hardware-dev-center/signing-with-the-new-2023-microsoft-uefi-certificates-what-submitters-need-to-kn/4455787
New signing requirements have also taken effect, and are available here: https://techcommunity.microsoft.com/blog/hardware-dev-center/updated-microsoft-uefi-signing-requirements/1062916 Please note that undergoing this shim review exempts you from yearly security audits, as long as your shim only hands off to open source boot loaders.
Hint: check the docs directory in this repo for guidance on submission and getting your shim signed.
Here's the template:
Organization name and website:
[your text here]
The reviewers should be able to easily verify, that your organization is a legal entity, to prevent abuse. Provide the information, which can prove the genuineness with certainty.
Company/tax register entries or equivalent:
(a link to the organization entry in your jurisdiction's register will do)
[your text here]
The public details of both your organization and the issuer in the EV certificate used for signing .cab files at Microsoft Hardware Dev Center File Signing Services.
(not the CA certificate embedded in your shim binary)
Example:``` Issuer: O=MyIssuer, Ltd., CN=MyIssuer EV Code Signing CA Subject: C=XX, O=MyCompany, Inc., CN=MyCompany, Inc.
*******************************************************************************
### यह किस उत्पाद या सेवा के लिए है?
*******************************************************************************
*******************************************************************************
### इस बात का औचित्य क्या है कि पूरी दुनिया को इसे बूट करने में सक्षम बनाने के लिए इस पर वास्तव में हस्ताक्षर होना आवश्यक है?
*******************************************************************************
*******************************************************************************
### आप किसी अन्य डिस्ट्रो से पहले से हस्ताक्षरित शिम का पुन: उपयोग करने में असमर्थ क्यों हैं?
*******************************************************************************
*******************************************************************************
### सुरक्षा अपडेट आदि के लिए प्राथमिक संपर्क कौन है?
सुरक्षा संपर्कों को shim स्वीकार किए जाने से पहले सत्यापित करने की आवश्यकता होती है। बाद के अनुरोधों के लिए, संपर्क सत्यापन केवल तभी आवश्यक है जब पिछले सफल सत्यापन के बाद से सुरक्षा संपर्क या उनकी PGP कुंजियाँ बदल गई हों।
एक अधिकृत समीक्षक प्रत्येक सुरक्षा संपर्क को यादृच्छिक शब्दों वाला PGP-एन्क्रिप्टेड ईमेल भेजकर संपर्क सत्यापन आरंभ करेगा।
आपसे इन ईमेलों की सामग्री को अपने `shim-review` issue में पोस्ट करने के लिए कहा जाएगा ताकि ईमेल पते और PGP कुंजियों के स्वामित्व को सिद्ध किया जा सके।
कृपया PGP कुंजियों को keyserver.ubuntu.com जैसे प्रसिद्ध keyserver पर अपलोड करें और/या उन्हें समीक्षा में .asc फ़ाइल के रूप में शामिल करें, और यहाँ उनकी ओर इंगित करें।
*******************************************************************************
- नाम:
- पद:
- ईमेल पता:
- PGP कुंजी फिंगरप्रिंट:
- फ़ाइल/keyserver स्थान:
*******************************************************************************
### सुरक्षा अपडेट आदि के लिए द्वितीयक संपर्क कौन है?
*******************************************************************************
- नाम:
- पद:
- ईमेल पता:
- PGP कुंजी फिंगरप्रिंट:
- फ़ाइल/keyserver स्थान:
*******************************************************************************
### क्या ये बाइनरी 16.1 shim रिलीज़ tar से बनाई गई हैं?
कृपया अपनी shim बाइनरी 16.1 shim रिलीज़ tar फ़ाइल से शुरू करके बनाएं: https://github.com/rhboot/shim/releases/download/16.1/shim-16.1.tar.bz2
यह https://github.com/rhboot/shim/releases/tag/16.1 से मेल खाता है और इसमें उपयुक्त gnu-efi स्रोत शामिल है।
सुनिश्चित करें कि tarball सही है, अपने डाउनलोड के चेकसम (SHA256, SHA512) को निम्नलिखित के साथ सत्यापित करके:```
46319cd228d8f2c06c744241c0f342412329a7c630436fce7f82cf6936b1d603 shim-16.1.tar.bz2
ca5f80e82f3b80b622028f03ef23105c98ee1b6a25f52a59c823080a3202dd4b9962266489296e99f955eb92e36ce13e0b1d57f688350006bba45f2718f159fb shim-16.1.tar.bz2
सुनिश्चित करें कि आपने जाँच कर ली है कि आपकी बिल्ड प्रक्रिया उस फ़ाइल को स्रोत के रूप में उपयोग करती है (बाहरी पैच को छोड़कर) और उसका चेकसम मेल खाता है। आप PGP हस्ताक्षर की जाँच करके भी रिलीज़ को और अधिक सत्यापित कर सकते हैं: एक अलग हस्ताक्षर यहाँ उपलब्ध है।
रिलीज़ पर मेंटेनर पीटर जोन्स (Peter Jones) द्वारा हस्ताक्षर किए गए हैं - उनकी मास्टर कुंजी का फिंगरप्रिंट B00B48BC731AA8840FED9FB0EED266B70F4FEF10 है और यहाँ हस्ताक्षर में मौजूद साइनिंग सब-कुंजी का फिंगरप्रिंट 02093E0D19DDE0F7DFFBB53C1FD3F540256A1372 है। उनकी सार्वजनिक कुंजी की एक प्रति संदर्भ के लिए यहाँ शामिल है:
pjones.asc
एक बार जब आप सुनिश्चित हो जाएँ कि आप जिस टारबॉल का उपयोग कर रहे हैं वह सही और प्रामाणिक है, तो कृपया इसे यहाँ एक साधारण हाँ के साथ पुष्टि करें।
सार्वजनिक कुंजियों और हस्ताक्षरों को सत्यापित करने के लिए एक संक्षिप्त मार्गदर्शिका docs निर्देशिका में उपलब्ध होनी चाहिए।
[आपका टेक्स्ट यहाँ]
संकेत: यदि आप अपने एप्लिकेशन में उपयोग किए जा रहे सभी पैच और संशोधनों को संलग्न करते हैं, तो आप यहाँ अपने एप्लिकेशन के URL की ओर इशारा कर सकते हैं (https://github.com/YOUR_ORGANIZATION/shim-review)।
आप अपने कस्टम git सर्वरों की ओर भी इशारा कर सकते हैं, जहाँ कोड होस्ट किया गया है।
[आपका URL यहाँ]
उन सभी बाहरी पैच और बिल्ड प्रक्रिया संशोधनों का उल्लेख करें, जो आपकी बिल्डिंग प्रक्रिया के दौरान उपयोग किए जाते हैं, जो आपके shim बाइनरी को वही बनाते हैं जो आपने इस एप्लिकेशन के भाग के रूप में पोस्ट किया है।
[आपका टेक्स्ट यहाँ]
NX बिट के बिना shim पर हस्ताक्षर करने के बारे में अधिक जानकारी के लिए https://techcommunity.microsoft.com/t5/hardware-dev-center/nx-exception-for-shim-community/ba-p/3976522 देखें।
[आपका टेक्स्ट यहाँ]
यदि आप GRUB2 का उपयोग नहीं कर रहे हैं, तो इसे छोड़ दें।
[आपका टेक्स्ट यहाँ]
यदि आप GRUB2 का उपयोग नहीं कर रहे हैं, तो इसे छोड़ दें, अन्यथा सुनिश्चित करें कि ये मौजूद हैं और हाँ के साथ पुष्टि करें।
[आपका टेक्स्ट यहाँ]
यदि आप GRUB2 का उपयोग नहीं कर रहे हैं, तो इसे छोड़ दें, अन्यथा क्या आपके GRUB2 बाइनरी में इसी प्रकार की एक प्रविष्टि है:
grub,5,Free Software Foundation,grub,GRUB_UPSTREAM_VERSION,https://www.gnu.org/software/grub/?
[आपका टेक्स्ट यहाँ]
यदि आपके पास पहले से हस्ताक्षरित shim नहीं था, तो यहाँ यह बताएँ। अन्यथा एक साधारण हाँ पर्याप्त होगा।
[आपका टेक्स्ट यहाँ]
संकेत: अपस्ट्रीम कर्नेल में ये सभी लागू होने चाहिए, लेकिन यदि आप अपना खुद का भारी-भरकम संशोधित पुराना कर्नेल संस्करण भेजते हैं, जिसे अपस्ट्रीम से अलग बनाए रखा जाता है, तो ऐसा नहीं हो सकता है। यदि आप एक पुराना कर्नेल भेज रहे हैं, तो अपने स्रोतों की दोबारा जाँच करें; हो सकता है कि आपके पास सभी पैच न हों, लेकिन आप एक ऐसा कॉन्फ़िगरेशन भेज रहे हों जो समस्या(ओं) को उजागर नहीं करता है।
[आपका टेक्स्ट यहाँ]
संकेत: यदि ऐसा नहीं करता है, तो हम आपके shim पर हस्ताक्षर करने की संभावना नहीं रखते हैं।
[आपका टेक्स्ट यहाँ]
[आपका टेक्स्ट यहाँ]
[आपका टेक्स्ट यहाँ]
[आपका टेक्स्ट यहाँ]
यह सुनिश्चित करता है कि आपका नया shim+GRUB2 उन पुराने GRUB2 बाइनरीज़ को समस्याओं के साथ चेनलोड नहीं कर सकता है।
यदि यह आपका पहला आवेदन है या आप एक नया CA प्रमाणपत्र उपयोग कर रहे हैं, तो कृपया यहाँ बताएँ।
[आपका टेक्स्ट यहाँ]
एक समीक्षक के लिए आपके आवेदन में संलग्न सटीक बाइनरी प्राप्त करने हेतु docker build . चलाना हमेशा संभव होना चाहिए।
संकेत: अपने टूलचेन के लिए फ्रोज़न पैकेज का उपयोग करना बेहतर है, क्योंकि GCC, binutils, gnu-efi में अपडेट से अलग चेकसम के साथ shim बाइनरी बन सकती है।
यदि प्रदान किए गए Dockerfile का उपयोग करके आपके shim बाइनरीज़ को पुन: उत्पन्न नहीं किया जा सकता है, तो कृपया बताएँ कि ऐसा क्यों है, अंतर क्या होंगे और इस बिल्ड को पुन: उत्पन्न करने के लिए किस बिल्ड वातावरण (OS और टूलचेन) का उपयोग किया जा रहा है? इस मामले में कृपया एक विस्तृत मार्गदर्शिका लिखें, कि इस बिल्ड वातावरण को शुरू से कैसे सेटअप किया जाए।
[आपका टेक्स्ट यहाँ]
इसमें बिल्डरूट्स बनाने, पैच लगाने, बिल्ड करने, अभिलेखागार बनाने आदि के लॉग शामिल होने चाहिए।
[आपका टेक्स्ट यहाँ]
उदाहरण के लिए, नए कर्नेल वेरिएंट, UKI, systemd-boot, नए प्रमाणपत्र, नया CA, आदि पर हस्ताक्षर करना।
यदि यह shim पर हस्ताक्षर करवाने का आपका पहला आवेदन है, तो इसे छोड़ दें।
[आपका टेक्स्ट यहाँ]
[आपका टेक्स्ट यहाँ]
कुंजी सुरक्षा के लिए उपयोग की जाने वाली सुरक्षा रणनीति का वर्णन करें। यह HSM या स्मार्टकार्ड जैसे हार्डवेयर टोकन, एयर-गैप्ड वॉल्ट, भौतिक तिजोरियों से लेकर अन्य अच्छी प्रथाओं तक हो सकती है।
[आपका टेक्स्ट यहाँ]
एक हाँ या नहीं पर्याप्त होगा। बाद के लिए कोई दंड नहीं है।
[आपका टेक्स्ट यहाँ]
एक हाँ या नहीं पर्याप्त होगा। बाद के लिए कोई दंड नहीं है। हालाँकि, यदि हाँ: क्या उस प्रमाणपत्र में X509v3 Basic Constraints शामिल हैं जो यह दर्शाता है कि यह एक CA है? इस बारे में अधिक मार्गदर्शन के लिए docs देखें।
[आपका टेक्स्ट यहाँ]
संकेत: SBAT का इतिहास और यह कैसे काम करता है इसके बारे में अधिक जानकारी यहाँ पाई जा सकती है। वह दस्तावेज़ बड़ा है, इसलिए कुछ उदाहरणों के लिए SBAT.example.md देखें।
यदि आप GRUB2 के डाउनस्ट्रीम कार्यान्वयन (जैसे Fedora या Debian से) का उपयोग कर रहे हैं, तो सुनिश्चित करें कि आपके पास उनकी SBAT प्रविष्टियाँ संरक्षित हैं और आप अपनी खुद की जोड़ते हैं (उन्हें प्रतिस्थापित न करें) ताकि निरस्तीकरण को सरल बनाया जा सके।
सभी बाइनरीज़ की प्रविष्टियाँ पोस्ट करना याद रखें। आपके बूटलोडर के अलावा, आप उदाहरण के लिए एक फर्मवेयर अपडेटर भी भेज रहे होंगे, जिसमें ये भी होंगे।
संकेत: इन प्रविष्टियों को प्राप्त करने के लिए objcopy --dump-section .sbat=/dev/stdout YOUR_EFI_BINARY चलाएँ। उन्हें यहाँ पेस्ट करें। अधिमानतः प्रत्येक सूची को तीन बैकटिक्स (```) से घेरें, ताकि वे अच्छी तरह से प्रदर्शित हों।
[आपका टेक्स्ट यहाँ]
यदि आप GRUB2 का उपयोग नहीं कर रहे हैं, तो इसे छोड़ दें।
संकेत: यह उन मॉड्यूल के बारे में है जो बाइनरी में ही हैं, न कि आपके फाइलसिस्टम में .mod फ़ाइलों के बारे में।
[आपका टेक्स्ट यहाँ]
[आपका टेक्स्ट यहाँ]
[आपका टेक्स्ट यहाँ]
संकेत: यहाँ सबसे सामान्य मामला fwupd जैसा एक फर्मवेयर अपडेटर होगा।
[आपका टेक्स्ट यहाँ]
यदि आप GRUB2 या systemd-boot का उपयोग नहीं कर रहे हैं, तो इसे छोड़ दें।
[आपका टेक्स्ट यहाँ]
एक या दो वाक्यों में संक्षेप में बताएँ कि आपकी सुरक्षित बूटचेन उच्च स्तर पर कैसे काम करती है।
[आपका टेक्स्ट यहाँ]
[आपका टेक्स्ट यहाँ]
[आपका टेक्स्ट यहाँ]
समीक्षा प्रक्रिया एक सहकर्मी-समीक्षा प्रयास होने के लिए है और आपके आवेदन की तेजी से समीक्षा करवाने का सबसे अच्छा तरीका दूसरों की समीक्षा में मदद करना है। अधिकांश मामलों में हम स्वयंसेवक हैं जो अपने खाली समय में इस कार्य पर काम करते हैं, न कि कार्य घंटों के दौरान आवेदनों की समीक्षा करने के लिए नियोजित और भुगतान पाने वाले।
समीक्षा के लिए प्रतीक्षा का एक उचित समय 2-3 महीने तक पहुँच सकता है। इस अवधि को छोटा करने का सबसे अच्छा तरीका हमारी मदद करना है। हमें जितनी अधिक मदद मिलेगी, चीजें उतनी ही तेज और सुचारू रूप से चलेंगी।
नए लोगों के लिए, समीक्षा करने में आसान के रूप में लेबल किए गए आवेदनों से योगदान प्रक्रिया शुरू करने की सिफारिश की जाती है।
[आपका टेक्स्ट यहाँ]
[आपका टेक्स्ट यहाँ]