Basic Gitea Information
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
बुनियादी Gitea वातावरण संरचना संस्थान(ओं) द्वारा रिपोजिटरी को समूहित करने के लिए है, जिनमें से प्रत्येक में कई रिपोजिटरी और कई टीमें हो सकती हैं। हालाँकि, ध्यान दें कि गिटहब की तरह, उपयोगकर्ताओं के पास संगठन के बाहर रिपोजिटरी हो सकती हैं।
इसके अलावा, एक उपयोगकर्ता विभिन्न संगठनों का सदस्य हो सकता है। संगठन के भीतर, उपयोगकर्ता के पास प्रत्येक रिपोजिटरी पर विभिन्न अनुमतियाँ हो सकती हैं।
एक उपयोगकर्ता विभिन्न टीमों का भी भाग हो सकता है जिनके पास विभिन्न रिपोजिटरी पर विभिन्न अनुमतियाँ होती हैं।
और अंत में, रिपोजिटरी में विशेष सुरक्षा तंत्र हो सकते हैं।
जब एक संगठन बनाया जाता है, तो एक टीम जिसे Owners कहा जाता है, बनाई जाती है और उपयोगकर्ता को इसके अंदर रखा जाता है। यह टीम संगठन पर व्यवस्थापक पहुँच प्रदान करेगी, ये अनुमतियाँ और टीम का नाम संशोधित नहीं किया जा सकता।
Org admins (owners) संगठन की दृश्यता का चयन कर सकते हैं:
सार्वजनिक
सीमित (लॉगिन किए गए उपयोगकर्ताओं के लिए केवल)
निजी (सदस्यों के लिए केवल)
Org admins यह भी संकेत कर सकते हैं कि क्या repo admins टीमों के लिए पहुँच जोड़ या हटा सकते हैं। वे अधिकतम रिपोजिटरी की संख्या भी संकेत कर सकते हैं।
नई टीम बनाते समय, कई महत्वपूर्ण सेटिंग्स चुनी जाती हैं:
यह संकेत दिया गया है कि टीम के सदस्यों को किस संगठन के रिपोजिटरी तक पहुँच प्राप्त होगी: विशिष्ट रिपोजिटरी (रिपोजिटरी जहाँ टीम जोड़ी गई है) या सभी।
यह भी संकेत दिया गया है कि क्या सदस्य नए रिपोजिटरी बना सकते हैं (निर्माता को इसके लिए व्यवस्थापक पहुँच प्राप्त होगी)
**रिपोजिटरी के सदस्यों के पास अनुमतियाँ होंगी:
व्यवस्थापक पहुँच
विशिष्ट पहुँच:
एक रिपोजिटरी में, org admin और repo admins (यदि संगठन द्वारा अनुमति दी गई हो) सहयोगियों (अन्य उपयोगकर्ताओं) और टीमों को दिए गए भूमिकाओं का प्रबंधन कर सकते हैं। वहाँ 3 संभावित भूमिकाएँ हैं:
व्यवस्थापक
लिखें
पढ़ें
उपयोगकर्ता नाम + पासवर्ड का उपयोग करना और संभावित रूप से (और अनुशंसित) 2FA।
आप अपने खाते को एक या एक से अधिक सार्वजनिक कुंजियों के साथ कॉन्फ़िगर कर सकते हैं जिससे संबंधित निजी कुंजी आपके पक्ष में कार्य करने की अनुमति देती है। http://localhost:3000/user/settings/keys
आप इन कुंजियों के साथ उपयोगकर्ता का अनुकरण नहीं कर सकते लेकिन यदि आप इसका उपयोग नहीं करते हैं तो यह संभव हो सकता है कि आप बिना हस्ताक्षर के कमिट भेजने के लिए खोजे जाएं।
आप अपने खाते तक पहुँच देने के लिए व्यक्तिगत पहुँच टोकन उत्पन्न कर सकते हैं। एक व्यक्तिगत पहुँच टोकन आपके खाते पर पूर्ण पहुँच देता है: http://localhost:3000/user/settings/applications
व्यक्तिगत पहुँच टोकनों की तरह, Oauth applications आपके खाते और उन स्थानों पर पूर्ण पहुँच प्राप्त करेंगे जहाँ आपके खाते को पहुँच प्राप्त है क्योंकि, जैसा कि docs में संकेत दिया गया है, स्कोप अभी तक समर्थित नहीं हैं:
डिप्लॉय कुंजियाँ रिपोजिटरी के लिए केवल पढ़ने या लिखने की पहुँच हो सकती हैं, इसलिए वे विशिष्ट रिपोजिटरी को समझौता करने के लिए दिलचस्प हो सकती हैं।
ब्रांच सुरक्षा का उद्देश्य उपयोगकर्ताओं को एक रिपोजिटरी का पूर्ण नियंत्रण नहीं देना है। लक्ष्य यह है कि कुछ ब्रांच के अंदर कोड लिखने से पहले कई सुरक्षा विधियों को लागू किया जाए।
एक रिपोजिटरी की ब्रांच सुरक्षा https://localhost:3000/<orgname>/<reponame>/settings/branches पर पाई जा सकती है।
यह संस्थान स्तर पर ब्रांच सुरक्षा सेट करना संभव नहीं है। इसलिए सभी को प्रत्येक रिपोजिटरी पर घोषित किया जाना चाहिए।
एक ब्रांच पर विभिन्न सुरक्षा लागू की जा सकती हैं (जैसे कि मास्टर पर):
पुश अक्षम करें: कोई भी इस ब्रांच पर पुश नहीं कर सकता
पुश सक्षम करें: पहुँच वाले कोई भी पुश कर सकते हैं, लेकिन बल पुश नहीं कर सकते।
व्हाइटलिस्ट प्रतिबंधित पुश सक्षम करें: केवल चयनित उपयोगकर्ता/टीम इस ब्रांच पर पुश कर सकते हैं (लेकिन बल पुश नहीं)
मर्ज व्हाइटलिस्ट सक्षम करें: केवल व्हाइटलिस्टेड उपयोगकर्ता/टीम PRs को मर्ज कर सकते हैं।
स्टेटस चेक सक्षम करें: मर्ज करने से पहले स्टेटस चेक पास करने की आवश्यकता है।
अनुमोदनों की आवश्यकता: यह संकेत करें कि PR को मर्ज करने से पहले कितने अनुमोदनों की आवश्यकता है।
व्हाइटलिस्टेड पर अनुमोदनों को प्रतिबंधित करें: उन उपयोगकर्ताओं/टीमों को संकेत करें जो PRs को अनुमोदित कर सकते हैं।
अस्वीकृत समीक्षाओं पर मर्ज को अवरुद्ध करें: यदि परिवर्तन अनुरोध किए जाते हैं, तो इसे मर्ज नहीं किया जा सकता (यहां तक कि यदि अन्य चेक पास होते हैं)
आधिकारिक समीक्षा अनुरोधों पर मर्ज को अवरुद्ध करें: यदि वहाँ आधिकारिक समीक्षा अनुरोध हैं, तो इसे मर्ज नहीं किया जा सकता
पुराने अनुमोदनों को अस्वीकार करें: जब नए कमिट होते हैं, तो पुराने अनुमोदन अस्वीकार कर दिए जाएंगे।
हस्ताक्षरित कमिट की आवश्यकता: कमिट को हस्ताक्षरित होना चाहिए।
यदि पुल अनुरोध पुराना है तो मर्ज को अवरुद्ध करें
संरक्षित/असंरक्षित फ़ाइल पैटर्न: फ़ाइलों के पैटर्न को परिवर्तनों के खिलाफ संरक्षित/असंरक्षित करने के लिए संकेत करें
जैसा कि आप देख सकते हैं, भले ही आप किसी उपयोगकर्ता के कुछ क्रेडेंशियल प्राप्त करने में सफल रहे हों, रिपोजिटरी सुरक्षा में हो सकती हैं जिससे आप उदाहरण के लिए मास्टर पर कोड पुश नहीं कर सकते जिससे CI/CD पाइपलाइन को समझौता किया जा सके।
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
