Skip to content
KitploitKITPLOIT
उपकरणब्लॉग
जमा करें
उपकरणब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
shim-review — shim की समीक्षाएँ | Kitploit
उपकरण/GitHubGitHub/rhboot/shim-review
भेद्यता विश्लेषणकोड विश्लेषणआपूर्ति श्रृंखला सुरक्षालर्निंग और शिक्षाचयनित संसाधनफर्मवेयर विश्लेषण
GitHubrhboot/shim-review

shim-review

shim की समीक्षाएँ

रिपॉजिटरी देखें
89171411 दिन पहलेKitploit द्वारा समीक्षित

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें

This repo is for review of requests for signing shim. To create a request for review:

  • clone this repo (preferably fork it)
  • edit the template below
  • add the shim.efi to be signed
  • add build logs
  • add any additional binaries/certificates/SHA256 hashes that may be needed
  • commit all of that
  • tag it with a tag of the form "myorg-shim-arch-YYYYMMDD"
  • push it to GitHub
  • file an issue at https://github.com/rhboot/shim-review/issues with a link to your tag
  • approval is ready when the "accepted" label is added to your issue

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:


What organization or people are asking to have this signed?


Organization name and website:
[your text here]


What's the legal data that proves the organization's genuineness?

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.

root@kitploit:~
*******************************************************************************
### यह किस उत्पाद या सेवा के लिए है?
*******************************************************************************

*******************************************************************************
### इस बात का औचित्य क्या है कि पूरी दुनिया को इसे बूट करने में सक्षम बनाने के लिए इस पर वास्तव में हस्ताक्षर होना आवश्यक है?
*******************************************************************************

*******************************************************************************
### आप किसी अन्य डिस्ट्रो से पहले से हस्ताक्षरित शिम का पुन: उपयोग करने में असमर्थ क्यों हैं?
*******************************************************************************

*******************************************************************************
### सुरक्षा अपडेट आदि के लिए प्राथमिक संपर्क कौन है?
सुरक्षा संपर्कों को 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 जिसमें वह सटीक कोड है जिसे बिल्ड करके आपका बाइनरी तैयार किया गया था:

संकेत: यदि आप अपने एप्लिकेशन में उपयोग किए जा रहे सभी पैच और संशोधनों को संलग्न करते हैं, तो आप यहाँ अपने एप्लिकेशन के URL की ओर इशारा कर सकते हैं (https://github.com/YOUR_ORGANIZATION/shim-review)।

आप अपने कस्टम git सर्वरों की ओर भी इशारा कर सकते हैं, जहाँ कोड होस्ट किया गया है।


[आपका URL यहाँ]


कौन से पैच लागू किए जा रहे हैं और क्यों:

उन सभी बाहरी पैच और बिल्ड प्रक्रिया संशोधनों का उल्लेख करें, जो आपकी बिल्डिंग प्रक्रिया के दौरान उपयोग किए जाते हैं, जो आपके shim बाइनरी को वही बनाते हैं जो आपने इस एप्लिकेशन के भाग के रूप में पोस्ट किया है।


[आपका टेक्स्ट यहाँ]


क्या आपके shim में NX बिट सेट है? यदि हाँ, तो क्या आपका संपूर्ण बूट स्टैक NX-संगत है और आपने ऐसी संगतता सुनिश्चित करने के लिए क्या परीक्षण किया है?

NX बिट के बिना shim पर हस्ताक्षर करने के बारे में अधिक जानकारी के लिए https://techcommunity.microsoft.com/t5/hardware-dev-center/nx-exception-for-shim-community/ba-p/3976522 देखें।


[आपका टेक्स्ट यहाँ]


GRUB2 में Secure Boot का आपके पास कौन सा सटीक कार्यान्वयन है? (या तो अपस्ट्रीम GRUB2 shim_lock वेरिफायर या डाउनस्ट्रीम RHEL/Fedora/Debian/Canonical-जैसा कार्यान्वयन)

यदि आप GRUB2 का उपयोग नहीं कर रहे हैं, तो इसे छोड़ दें।


[आपका टेक्स्ट यहाँ]


क्या आपके पास निम्नलिखित सभी GRUB2 CVE के लिए फिक्स लागू हैं?

यदि आप GRUB2 का उपयोग नहीं कर रहे हैं, तो इसे छोड़ दें, अन्यथा सुनिश्चित करें कि ये मौजूद हैं और हाँ के साथ पुष्टि करें।

  • 2020 जुलाई - BootHole
    • विवरण: https://lists.gnu.org/archive/html/grub-devel/2020-07/msg00034.html
    • CVE-2020-10713
    • CVE-2020-14308
    • CVE-2020-14309
    • CVE-2020-14310
    • CVE-2020-14311
    • CVE-2020-15705
    • CVE-2020-15706
    • CVE-2020-15707
  • मार्च 2021
    • विवरण: https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00007.html
    • CVE-2020-14372
    • CVE-2020-25632
    • CVE-2020-25647
    • CVE-2020-27749
    • CVE-2020-27779
    • CVE-2021-3418 (यदि आप shim_lock मॉड्यूल भेज रहे हैं)
    • CVE-2021-20225
    • CVE-2021-20233
  • जून 2022
    • विवरण: https://lists.gnu.org/archive/html/grub-devel/2022-06/msg00035.html, SBAT वृद्धि से 2
    • CVE-2021-3695
    • CVE-2021-3696
    • CVE-2021-3697
    • CVE-2022-28733
    • CVE-2022-28734
    • CVE-2022-28735
    • CVE-2022-28736
    • CVE-2022-28737
  • नवंबर 2022
    • विवरण: https://lists.gnu.org/archive/html/grub-devel/2022-11/msg00059.html, SBAT वृद्धि से 3
    • CVE-2022-2601
    • CVE-2022-3775
  • अक्टूबर 2023 - NTFS कमजोरियाँ
    • विवरण: https://lists.gnu.org/archive/html/grub-devel/2023-10/msg00028.html, SBAT वृद्धि से 4
    • CVE-2023-4693
    • CVE-2023-4692
  • फरवरी 2025
    • विवरण: https://lists.gnu.org/archive/html/grub-devel/2025-02/msg00024.html, SBAT वृद्धि से 5
    • CVE-2024-45774
    • CVE-2024-45775
    • CVE-2024-45776
    • CVE-2024-45777
    • CVE-2024-45778
    • CVE-2024-45779
    • CVE-2024-45780
    • CVE-2024-45781
    • CVE-2024-45782
    • CVE-2024-45783
    • CVE-2025-0622
    • CVE-2025-0624
    • CVE-2025-0677
    • CVE-2025-0678
    • CVE-2025-0684
    • CVE-2025-0685
    • CVE-2025-0686
    • CVE-2025-0689
    • CVE-2025-0690
    • CVE-2025-1118
    • CVE-2025-1125

[आपका टेक्स्ट यहाँ]


यदि shim GRUB2 बूटलोडर लोड कर रहा है, और यदि ये फिक्स लागू किए गए हैं, तो क्या आपके GRUB2 बाइनरी में अपस्ट्रीम वैश्विक SBAT जनरेशन 5 पर सेट है?

यदि आप GRUB2 का उपयोग नहीं कर रहे हैं, तो इसे छोड़ दें, अन्यथा क्या आपके GRUB2 बाइनरी में इसी प्रकार की एक प्रविष्टि है: grub,5,Free Software Foundation,grub,GRUB_UPSTREAM_VERSION,https://www.gnu.org/software/grub/?


[आपका टेक्स्ट यहाँ]


क्या पुराने shim हैश Microsoft को सत्यापन के लिए और भविष्य के DBX अपडेट में जोड़े जाने हेतु प्रदान किए गए थे?

क्या आपकी नई विश्वास श्रृंखला CVE से प्रभावित पुराने GRUB2 बिल्ड को बूट करने की अनुमति नहीं देती है?

यदि आपके पास पहले से हस्ताक्षरित shim नहीं था, तो यहाँ यह बताएँ। अन्यथा एक साधारण हाँ पर्याप्त होगा।


[आपका टेक्स्ट यहाँ]


यदि आपकी बूट विश्वास श्रृंखला में Linux कर्नेल शामिल है:

क्या अपस्ट्रीम कमिट 1957a85b0032a81e6482ca4aab883643b8dae06e "efi: Restrict efivar_ssdt_load when the kernel is locked down" लागू है?

क्या अपस्ट्रीम कमिट 75b0cea7bf307f362057cc778efe89af4c615354 "ACPI: configfs: Disallow loading ACPI tables when locked down" लागू है?

क्या अपस्ट्रीम कमिट eadb2f47a3ced5c64b23b90fd2a3463f63726066 "lockdown: also lock down previous kgdb use" लागू है?

संकेत: अपस्ट्रीम कर्नेल में ये सभी लागू होने चाहिए, लेकिन यदि आप अपना खुद का भारी-भरकम संशोधित पुराना कर्नेल संस्करण भेजते हैं, जिसे अपस्ट्रीम से अलग बनाए रखा जाता है, तो ऐसा नहीं हो सकता है। यदि आप एक पुराना कर्नेल भेज रहे हैं, तो अपने स्रोतों की दोबारा जाँच करें; हो सकता है कि आपके पास सभी पैच न हों, लेकिन आप एक ऐसा कॉन्फ़िगरेशन भेज रहे हों जो समस्या(ओं) को उजागर नहीं करता है।


[आपका टेक्स्ट यहाँ]


जब आपका सिस्टम Secure Boot सक्षम के साथ चलता है तो आपका हस्ताक्षरित कर्नेल lockdown को कैसे लागू करता है?

संकेत: यदि ऐसा नहीं करता है, तो हम आपके shim पर हस्ताक्षर करने की संभावना नहीं रखते हैं।


[आपका टेक्स्ट यहाँ]


क्या आप अपने हस्ताक्षरित कर्नेल को अतिरिक्त स्थानीय पैच के साथ बिल्ड करते हैं? वे क्या करते हैं?


[आपका टेक्स्ट यहाँ]


क्या आप कर्नेल मॉड्यूल पर हस्ताक्षर करने के लिए एक अस्थायी कुंजी का उपयोग करते हैं?

यदि नहीं, तो कृपया बताएँ कि आप कैसे सुनिश्चित करते हैं कि एक कर्नेल बिल्ड किसी अन्य कर्नेल के लिए बनाए गए मॉड्यूल को लोड नहीं करता है।


[आपका टेक्स्ट यहाँ]


यदि आप कई प्रमाणपत्रों और/या हैश प्रदान करने की vendor_db कार्यक्षमता का उपयोग करते हैं, तो कृपया अपने प्रमाणपत्र सेटअप का संक्षेप में वर्णन करें।

यदि अनुमत-सूचीबद्ध हैश हैं, तो कृपया उन सटीक बाइनरीज़ प्रदान करें जिनके लिए हैश फ़ाइल साझाकरण सेवा के माध्यम से बनाए गए हैं, जो सत्यापन के लिए अनाम पहुँच के साथ सार्वजनिक रूप से उपलब्ध हो।


[आपका टेक्स्ट यहाँ]


यदि आप अपने पिछले shim बाइनरी से CA प्रमाणपत्र का पुनः उपयोग कर रहे हैं, तो आपको shim में vendor_dbx में पहले उल्लिखित CVE से प्रभावित पिछले GRUB2 बाइनरीज़ के हैश जोड़ने होंगे। कृपया अपनी रणनीति का वर्णन करें।

यह सुनिश्चित करता है कि आपका नया shim+GRUB2 उन पुराने GRUB2 बाइनरीज़ को समस्याओं के साथ चेनलोड नहीं कर सकता है।

यदि यह आपका पहला आवेदन है या आप एक नया CA प्रमाणपत्र उपयोग कर रहे हैं, तो कृपया यहाँ बताएँ।


[आपका टेक्स्ट यहाँ]


क्या आपके रिपॉजिटरी में Dockerfile आपके shim बाइनरी के निर्माण को पुन: उत्पन्न करने की विधि है?

एक समीक्षक के लिए आपके आवेदन में संलग्न सटीक बाइनरी प्राप्त करने हेतु docker build . चलाना हमेशा संभव होना चाहिए।

संकेत: अपने टूलचेन के लिए फ्रोज़न पैकेज का उपयोग करना बेहतर है, क्योंकि GCC, binutils, gnu-efi में अपडेट से अलग चेकसम के साथ shim बाइनरी बन सकती है।

यदि प्रदान किए गए Dockerfile का उपयोग करके आपके shim बाइनरीज़ को पुन: उत्पन्न नहीं किया जा सकता है, तो कृपया बताएँ कि ऐसा क्यों है, अंतर क्या होंगे और इस बिल्ड को पुन: उत्पन्न करने के लिए किस बिल्ड वातावरण (OS और टूलचेन) का उपयोग किया जा रहा है? इस मामले में कृपया एक विस्तृत मार्गदर्शिका लिखें, कि इस बिल्ड वातावरण को शुरू से कैसे सेटअप किया जाए।


[आपका टेक्स्ट यहाँ]


इस रेपो में कौन सी फ़ाइलें आपके बिल्ड के लॉग हैं?

इसमें बिल्डरूट्स बनाने, पैच लगाने, बिल्ड करने, अभिलेखागार बनाने आदि के लॉग शामिल होने चाहिए।


[आपका टेक्स्ट यहाँ]


आपके SHIM पर पिछली बार हस्ताक्षर किए जाने के बाद से डिस्ट्रो की सुरक्षित बूट श्रृंखला में क्या परिवर्तन किए गए?

उदाहरण के लिए, नए कर्नेल वेरिएंट, UKI, systemd-boot, नए प्रमाणपत्र, नया CA, आदि पर हस्ताक्षर करना।

यदि यह shim पर हस्ताक्षर करवाने का आपका पहला आवेदन है, तो इसे छोड़ दें।


[आपका टेक्स्ट यहाँ]


आपके अंतिम shim बाइनरी का SHA256 हैश क्या है?


[आपका टेक्स्ट यहाँ]


आप अपने shim में उपयोग की जाने वाली कुंजियों को कैसे प्रबंधित और सुरक्षित रखते हैं?

कुंजी सुरक्षा के लिए उपयोग की जाने वाली सुरक्षा रणनीति का वर्णन करें। यह HSM या स्मार्टकार्ड जैसे हार्डवेयर टोकन, एयर-गैप्ड वॉल्ट, भौतिक तिजोरियों से लेकर अन्य अच्छी प्रथाओं तक हो सकती है।


[आपका टेक्स्ट यहाँ]


क्या आप shim में एम्बेडेड प्रमाणपत्र के रूप में EV प्रमाणपत्र का उपयोग करते हैं?

एक हाँ या नहीं पर्याप्त होगा। बाद के लिए कोई दंड नहीं है।


[आपका टेक्स्ट यहाँ]


क्या आप अपने shim में एक CA प्रमाणपत्र एम्बेड कर रहे हैं?

एक हाँ या नहीं पर्याप्त होगा। बाद के लिए कोई दंड नहीं है। हालाँकि, यदि हाँ: क्या उस प्रमाणपत्र में X509v3 Basic Constraints शामिल हैं जो यह दर्शाता है कि यह एक CA है? इस बारे में अधिक मार्गदर्शन के लिए docs देखें।


[आपका टेक्स्ट यहाँ]


क्या आप प्रत्येक बाइनरी में SBAT सेक्शन में एक विक्रेता-विशिष्ट SBAT प्रविष्टि जोड़ते हैं जो SBAT मेटाडेटा का समर्थन करता है (GRUB2, fwupd, fwupdate, systemd-boot, systemd-stub, shim + सभी चाइल्ड shim बाइनरीज़)?

कृपया उन सभी बाइनरीज़ के लिए सटीक SBAT प्रविष्टियाँ प्रदान करें जिन्हें आप सीधे shim के माध्यम से बूट कर रहे हैं।

संकेत: SBAT का इतिहास और यह कैसे काम करता है इसके बारे में अधिक जानकारी यहाँ पाई जा सकती है। वह दस्तावेज़ बड़ा है, इसलिए कुछ उदाहरणों के लिए SBAT.example.md देखें।

यदि आप GRUB2 के डाउनस्ट्रीम कार्यान्वयन (जैसे Fedora या Debian से) का उपयोग कर रहे हैं, तो सुनिश्चित करें कि आपके पास उनकी SBAT प्रविष्टियाँ संरक्षित हैं और आप अपनी खुद की जोड़ते हैं (उन्हें प्रतिस्थापित न करें) ताकि निरस्तीकरण को सरल बनाया जा सके।

सभी बाइनरीज़ की प्रविष्टियाँ पोस्ट करना याद रखें। आपके बूटलोडर के अलावा, आप उदाहरण के लिए एक फर्मवेयर अपडेटर भी भेज रहे होंगे, जिसमें ये भी होंगे।

संकेत: इन प्रविष्टियों को प्राप्त करने के लिए objcopy --dump-section .sbat=/dev/stdout YOUR_EFI_BINARY चलाएँ। उन्हें यहाँ पेस्ट करें। अधिमानतः प्रत्येक सूची को तीन बैकटिक्स (```) से घेरें, ताकि वे अच्छी तरह से प्रदर्शित हों।


[आपका टेक्स्ट यहाँ]


यदि shim GRUB2 बूटलोडर लोड कर रहा है, तो आपकी हस्ताक्षरित GRUB2 छवि में कौन से मॉड्यूल बिल्ट-इन हैं?

यदि आप GRUB2 का उपयोग नहीं कर रहे हैं, तो इसे छोड़ दें।

संकेत: यह उन मॉड्यूल के बारे में है जो बाइनरी में ही हैं, न कि आपके फाइलसिस्टम में .mod फ़ाइलों के बारे में।


[आपका टेक्स्ट यहाँ]


यदि आप arm64 या riscv पर systemd-boot का उपयोग कर रहे हैं, तो क्या असत्यापित Devicetree Blob लोडिंग के लिए फिक्स शामिल है?


[आपका टेक्स्ट यहाँ]


आपके बूटलोडर (GRUB2 या systemd-boot या अन्य) की उत्पत्ति और पूर्ण संस्करण संख्या क्या है?


[आपका टेक्स्ट यहाँ]


यदि आपका shim आपके बूटलोडर के अलावा किसी अन्य घटक को लॉन्च करता है, तो कृपया लॉन्च किए जाने वाले के बारे में अधिक विवरण प्रदान करें।

संकेत: यहाँ सबसे सामान्य मामला fwupd जैसा एक फर्मवेयर अपडेटर होगा।


[आपका टेक्स्ट यहाँ]


यदि आपका GRUB2 या systemd-boot SecureBoot मोड में Linux कर्नेल के अलावा किसी अन्य बाइनरी को लॉन्च करता है, तो कृपया लॉन्च किए जाने वाले के बारे में अधिक विवरण प्रदान करें और यह Secureboot lockdown को कैसे लागू करता है।

यदि आप GRUB2 या systemd-boot का उपयोग नहीं कर रहे हैं, तो इसे छोड़ दें।


[आपका टेक्स्ट यहाँ]


लॉन्च किए गए घटक बिना प्रमाणीकरण वाले कोड के निष्पादन को कैसे रोकते हैं?

एक या दो वाक्यों में संक्षेप में बताएँ कि आपकी सुरक्षित बूटचेन उच्च स्तर पर कैसे काम करती है।


[आपका टेक्स्ट यहाँ]


क्या आपका shim ऐसे किसी लोडर को लोड करता है जो बिना हस्ताक्षर वाले कर्नेल को लोड करने का समर्थन करता है (जैसे कुछ GRUB2 कॉन्फ़िगरेशन)?


[आपका टेक्स्ट यहाँ]


आप कौन सा कर्नेल उपयोग कर रहे हैं? Secure Boot को लागू करने के लिए इसमें कौन से पैच और कॉन्फ़िगरेशन शामिल हैं?


[आपका टेक्स्ट यहाँ]


अन्य आवेदकों के आवेदनों की समीक्षा करने में हमारी सहायता करने के लिए आपने क्या योगदान दिया है?

समीक्षा प्रक्रिया एक सहकर्मी-समीक्षा प्रयास होने के लिए है और आपके आवेदन की तेजी से समीक्षा करवाने का सबसे अच्छा तरीका दूसरों की समीक्षा में मदद करना है। अधिकांश मामलों में हम स्वयंसेवक हैं जो अपने खाली समय में इस कार्य पर काम करते हैं, न कि कार्य घंटों के दौरान आवेदनों की समीक्षा करने के लिए नियोजित और भुगतान पाने वाले।

समीक्षा के लिए प्रतीक्षा का एक उचित समय 2-3 महीने तक पहुँच सकता है। इस अवधि को छोटा करने का सबसे अच्छा तरीका हमारी मदद करना है। हमें जितनी अधिक मदद मिलेगी, चीजें उतनी ही तेज और सुचारू रूप से चलेंगी।

नए लोगों के लिए, समीक्षा करने में आसान के रूप में लेबल किए गए आवेदनों से योगदान प्रक्रिया शुरू करने की सिफारिश की जाती है।


[आपका टेक्स्ट यहाँ]


कोई भी अतिरिक्त जानकारी जोड़ें जो आपको लगता है कि हमें इस shim साइनिंग आवेदन को मान्य करने के लिए आवश्यक हो सकती है।


[आपका टेक्स्ट यहाँ]

टूल डाउनलोड करें