Basic Gitea Information

Support HackTricks

Basic Structure

बुनियादी Gitea वातावरण संरचना संस्थान(ओं) द्वारा रिपोजिटरी को समूहित करने के लिए है, जिनमें से प्रत्येक में कई रिपोजिटरी और कई टीमें हो सकती हैं। हालाँकि, ध्यान दें कि गिटहब की तरह, उपयोगकर्ताओं के पास संगठन के बाहर रिपोजिटरी हो सकती हैं।

इसके अलावा, एक उपयोगकर्ता विभिन्न संगठनों का सदस्य हो सकता है। संगठन के भीतर, उपयोगकर्ता के पास प्रत्येक रिपोजिटरी पर विभिन्न अनुमतियाँ हो सकती हैं।

एक उपयोगकर्ता विभिन्न टीमों का भी भाग हो सकता है जिनके पास विभिन्न रिपोजिटरी पर विभिन्न अनुमतियाँ होती हैं।

और अंत में, रिपोजिटरी में विशेष सुरक्षा तंत्र हो सकते हैं

Permissions

Organizations

जब एक संगठन बनाया जाता है, तो एक टीम जिसे Owners कहा जाता है, बनाई जाती है और उपयोगकर्ता को इसके अंदर रखा जाता है। यह टीम संगठन पर व्यवस्थापक पहुंच प्रदान करेगी, ये अनुमतियाँ और टीम का नाम संशोधित नहीं किया जा सकता

Org admins (owners) संगठन की दृश्यता का चयन कर सकते हैं:

  • सार्वजनिक

  • सीमित (लॉग इन उपयोगकर्ताओं के लिए केवल)

  • निजी (सदस्यों के लिए केवल)

Org admins यह भी संकेत कर सकते हैं कि क्या repo admins टीमों के लिए पहुंच जोड़ या हटा सकते हैं। वे अधिकतम रिपोजिटरी की संख्या भी संकेत कर सकते हैं।

नई टीम बनाते समय, कई महत्वपूर्ण सेटिंग्स चुनी जाती हैं:

  • यह संकेत दिया गया है कि टीम के सदस्यों को किस संगठन के रिपोजिटरी तक पहुंच प्राप्त होगी: विशिष्ट रिपोजिटरी (रिपोजिटरी जहां टीम जोड़ी गई है) या सभी।

  • यह भी संकेत दिया गया है कि क्या सदस्य नए रिपोजिटरी बना सकते हैं (निर्माता को इसके लिए व्यवस्थापक पहुंच प्राप्त होगी)

  • रिपोजिटरी के सदस्यों के पास जो अनुमतियाँ होंगी:

  • व्यवस्थापक पहुंच

  • विशिष्ट पहुंच:

Teams & Users

एक रिपोजिटरी में, org admin और repo admins (यदि संगठन द्वारा अनुमति दी गई हो) सहयोगियों (अन्य उपयोगकर्ताओं) और टीमों को दिए गए भूमिकाओं का प्रबंधन कर सकते हैं। वहाँ 3 संभावित भूमिकाएँ हैं:

  • व्यवस्थापक

  • लिखें

  • पढ़ें

Gitea Authentication

Web Access

उपयोगकर्ता नाम + पासवर्ड का उपयोग करना और संभावित रूप से (और अनुशंसित) 2FA।

SSH Keys

आप अपने खाते को एक या एक से अधिक सार्वजनिक कुंजियों के साथ कॉन्फ़िगर कर सकते हैं जो संबंधित निजी कुंजी को आपके पक्ष में कार्य करने की अनुमति देती हैं। http://localhost:3000/user/settings/keys

GPG Keys

आप इन कुंजियों के साथ उपयोगकर्ता का अनुकरण नहीं कर सकते लेकिन यदि आप इसका उपयोग नहीं करते हैं तो यह संभव हो सकता है कि आप बिना हस्ताक्षर के कमिट भेजने के लिए खोजे जाएं

Personal Access Tokens

आप एक एप्लिकेशन को अपने खाते तक पहुंच देने के लिए व्यक्तिगत पहुंच टोकन उत्पन्न कर सकते हैं। एक व्यक्तिगत पहुंच टोकन आपके खाते पर पूर्ण पहुंच देता है: http://localhost:3000/user/settings/applications

Oauth Applications

व्यक्तिगत पहुंच टोकन की तरह, Oauth applications आपके खाते और उन स्थानों पर पूर्ण पहुंच प्राप्त करेंगे जहां आपके खाते को पहुंच प्राप्त है क्योंकि, जैसा कि docs में संकेत दिया गया है, स्कोप अभी तक समर्थित नहीं हैं:

Deploy keys

डिप्लॉय कुंजियों को रिपोजिटरी के लिए केवल पढ़ने या लिखने की पहुंच हो सकती है, इसलिए वे विशिष्ट रिपोजिटरी को समझौता करने के लिए दिलचस्प हो सकते हैं।

Branch Protections

ब्रांच सुरक्षा का उद्देश्य उपयोगकर्ताओं को एक रिपोजिटरी का पूर्ण नियंत्रण नहीं देना है। लक्ष्य यह है कि कुछ ब्रांच के अंदर कोड लिखने में सक्षम होने से पहले कई सुरक्षा विधियों को लागू किया जाए

एक रिपोजिटरी की ब्रांच सुरक्षा https://localhost:3000/<orgname>/<reponame>/settings/branches में पाई जा सकती है।

यह संस्थान स्तर पर ब्रांच सुरक्षा सेट करना संभव नहीं है। इसलिए सभी को प्रत्येक रिपोजिटरी पर घोषित किया जाना चाहिए।

एक ब्रांच पर विभिन्न सुरक्षा लागू की जा सकती हैं (जैसे कि मास्टर पर):

  • पुश अक्षम करें: कोई भी इस ब्रांच पर पुश नहीं कर सकता

  • पुश सक्षम करें: जो कोई भी पहुंच के साथ है वह पुश कर सकता है, लेकिन बल पुश नहीं कर सकता।

  • व्हाइटलिस्ट प्रतिबंधित पुश: केवल चयनित उपयोगकर्ता/टीम इस ब्रांच पर पुश कर सकते हैं (लेकिन कोई बल पुश नहीं)

  • मर्ज व्हाइटलिस्ट सक्षम करें: केवल व्हाइटलिस्टेड उपयोगकर्ता/टीम PRs को मर्ज कर सकते हैं।

  • स्टेटस चेक सक्षम करें: मर्ज करने से पहले स्टेटस चेक पास करने की आवश्यकता है।

  • अनुमोदनों की आवश्यकता: यह संकेत करें कि PR को मर्ज करने से पहले कितने अनुमोदनों की आवश्यकता है।

  • व्हाइटलिस्टेड को अनुमोदनों तक सीमित करें: उन उपयोगकर्ताओं/टीमों को संकेत करें जो PRs को अनुमोदित कर सकते हैं।

  • अस्वीकृत समीक्षाओं पर मर्ज को अवरुद्ध करें: यदि परिवर्तन अनुरोध किए जाते हैं, तो इसे मर्ज नहीं किया जा सकता (यहां तक कि यदि अन्य चेक पास होते हैं)

  • आधिकारिक समीक्षा अनुरोधों पर मर्ज को अवरुद्ध करें: यदि वहां आधिकारिक समीक्षा अनुरोध हैं, तो इसे मर्ज नहीं किया जा सकता

  • पुराने अनुमोदनों को अस्वीकार करें: जब नए कमिट होते हैं, तो पुराने अनुमोदनों को अस्वीकार कर दिया जाएगा।

  • हस्ताक्षरित कमिट की आवश्यकता: कमिट को हस्ताक्षरित होना चाहिए।

  • यदि पुल अनुरोध पुराना है तो मर्ज को अवरुद्ध करें

  • संरक्षित/असंरक्षित फ़ाइल पैटर्न: परिवर्तनों के खिलाफ सुरक्षा/असंरक्षित करने के लिए फ़ाइलों के पैटर्न को संकेत करें

जैसा कि आप देख सकते हैं, भले ही आप किसी उपयोगकर्ता के कुछ क्रेडेंशियल प्राप्त करने में सफल रहे हों, रिपोजिटरी को सुरक्षित किया जा सकता है जिससे आप उदाहरण के लिए मास्टर पर कोड पुश करने से रोक सकते हैं ताकि CI/CD पाइपलाइन को समझौता किया जा सके।

Support HackTricks

Last updated