फ़ायरफ़ॉक्स में हाल ही में ऐड-ऑन को अक्षम करने का तकनीकी विवरण

टिप्पणी अनुवादक: पाठकों की सुविधा के लिए तारीखें मास्को समय के अनुसार दी गई हैं

हम हाल ही में ऐड-ऑन पर हस्ताक्षर करने के लिए उपयोग किए जाने वाले प्रमाणपत्रों में से एक की समाप्ति से चूक गए। इसके परिणामस्वरूप उपयोगकर्ताओं के लिए ऐड-ऑन अक्षम हो गए। अब जबकि समस्या काफी हद तक ठीक हो गई है, मैं जो कुछ हुआ और जो काम किया गया उसका विवरण साझा करना चाहूंगा।

पृष्ठभूमि: परिवर्धन और हस्ताक्षर

हालाँकि बहुत से लोग ब्राउज़र का उपयोग बॉक्स से बाहर करते हैं, फ़ायरफ़ॉक्स "ऐड-ऑन" नामक एक्सटेंशन का समर्थन करता है। इनकी मदद से यूजर्स ब्राउजर में कई तरह के फीचर्स जोड़ते हैं। 15 हजार से अधिक ऐड-ऑन हैं: से विज्ञापन अवरोधन से सैकड़ों टैब प्रबंधित करें.

इंस्टॉल किए गए ऐड-ऑन अवश्य होने चाहिए अंगुली का हस्ताक्षर, जो उपयोगकर्ताओं को दुर्भावनापूर्ण ऐड-ऑन से बचाता है और मोज़िला स्टाफ द्वारा ऐड-ऑन की न्यूनतम समीक्षा की आवश्यकता होती है। हमने यह आवश्यकता 2015 में पेश की थी क्योंकि हम अनुभव कर रहे थे गंभीर समस्याएं दुर्भावनापूर्ण ऐड-ऑन के साथ.

यह कैसे काम करता है: फ़ायरफ़ॉक्स की प्रत्येक प्रति में एक "रूट प्रमाणपत्र" होता है। इस "रूट" की कुंजी संग्रहीत है हार्डवेयर सुरक्षा मॉड्यूल (एचएसएम)बिना नेटवर्क एक्सेस के. हर कुछ वर्षों में, इस कुंजी के साथ एक नए "मध्यवर्ती प्रमाणपत्र" पर हस्ताक्षर किए जाते हैं, जिसका उपयोग ऐड-ऑन पर हस्ताक्षर करते समय किया जाता है। जब कोई डेवलपर ऐड-ऑन सबमिट करता है, तो हम एक अस्थायी "अंत प्रमाणपत्र" बनाते हैं और एक मध्यवर्ती प्रमाणपत्र का उपयोग करके उस पर हस्ताक्षर करते हैं। इसके बाद ऐड-ऑन पर अंतिम प्रमाणपत्र के साथ हस्ताक्षर किए जाते हैं। रेखाचित्र के रूप में यह इस तरह दिख रहा है.

कृपया ध्यान दें कि प्रत्येक प्रमाणपत्र में एक "विषय" (जिसे प्रमाणपत्र जारी किया गया था) और एक "जारीकर्ता" (जिसने प्रमाणपत्र जारी किया) होता है। रूट प्रमाणपत्र के मामले में, "विषय" = "जारीकर्ता", लेकिन अन्य प्रमाणपत्रों के लिए, प्रमाणपत्र जारीकर्ता मूल प्रमाणपत्र का विषय है जिसके द्वारा यह हस्ताक्षरित है।

एक महत्वपूर्ण बिंदु: प्रत्येक ऐड-ऑन पर एक अद्वितीय अंतिम प्रमाणपत्र द्वारा हस्ताक्षर किए जाते हैं, लेकिन लगभग हमेशा ये अंतिम प्रमाणपत्र एक ही मध्यवर्ती प्रमाणपत्र द्वारा हस्ताक्षरित होते हैं।

लेखक का नोट: अपवाद बहुत पुराने जोड़ हैं। उस समय, विभिन्न मध्यवर्ती प्रमाणपत्रों का उपयोग किया जाता था।

इस मध्यवर्ती प्रमाणपत्र के कारण समस्याएँ उत्पन्न हुईं: प्रत्येक प्रमाणपत्र एक निश्चित अवधि के लिए वैध होता है। इस अवधि से पहले या बाद में, प्रमाणपत्र अमान्य है और ब्राउज़र इस प्रमाणपत्र द्वारा हस्ताक्षरित ऐड-ऑन का उपयोग नहीं करेगा। दुर्भाग्य से, इंटरमीडिएट प्रमाणपत्र 4 मई को सुबह 4 बजे समाप्त हो गया।

परिणाम तुरंत सामने नहीं आये. फ़ायरफ़ॉक्स इंस्टॉल किए गए ऐड-ऑन के हस्ताक्षरों की लगातार जाँच नहीं करता है, बल्कि लगभग हर 24 घंटे में एक बार जाँचता है, और सत्यापन का समय प्रत्येक उपयोगकर्ता के लिए अलग-अलग होता है। परिणामस्वरूप, कुछ लोगों को तुरंत समस्याओं का अनुभव हुआ, जबकि अन्य को बहुत बाद में समस्याओं का अनुभव हुआ। प्रमाणपत्र की समय सीमा समाप्त होने के समय हमें पहली बार समस्या का पता चला और हमने तुरंत इसका समाधान ढूंढना शुरू कर दिया।

क्षति को कम करना

एक बार जब हमें एहसास हुआ कि क्या हुआ था, हमने स्थिति को बदतर होने से रोकने की कोशिश की।

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

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

समानांतर संचालन

सिद्धांत रूप में, समस्या का समाधान सरल दिखता है: एक नया वैध मध्यवर्ती प्रमाणपत्र बनाएं और प्रत्येक ऐड-ऑन पर फिर से हस्ताक्षर करें। दुर्भाग्य से यह काम नहीं करेगा:

  • हम एक साथ 15 हजार ऐड-ऑन पर जल्दी से दोबारा हस्ताक्षर नहीं कर सकते, सिस्टम इतने लोड के लिए डिज़ाइन नहीं किया गया है
  • हमारे द्वारा परिवर्धन पर हस्ताक्षर करने के बाद, अद्यतन संस्करणों को उपयोगकर्ताओं तक पहुंचाया जाना आवश्यक है। अधिकांश ऐड-ऑन मोज़िला सर्वर से इंस्टॉल किए जाते हैं, इसलिए फ़ायरफ़ॉक्स को अगले XNUMX घंटों के भीतर अपडेट मिल जाएगा, लेकिन कुछ डेवलपर्स तीसरे पक्ष के चैनलों के माध्यम से हस्ताक्षरित ऐड-ऑन वितरित करते हैं, इसलिए उपयोगकर्ताओं को ऐसे ऐड-ऑन को मैन्युअल रूप से अपडेट करना होगा

इसके बजाय, हमने एक ऐसा समाधान विकसित करने का प्रयास किया जो सभी उपयोगकर्ताओं तक उनकी ओर से बहुत अधिक या कोई कार्रवाई किए बिना पहुंचेगा।

बहुत जल्दी हम दो मुख्य रणनीतियों पर पहुंचे, जिनका हमने समानांतर में उपयोग किया:

  • प्रमाणपत्र वैधता अवधि बदलने के लिए फ़ायरफ़ॉक्स अपडेट करें। इससे मौजूदा ऐड-ऑन फिर से जादुई तरीके से काम करने लगेंगे, लेकिन इसके लिए फ़ायरफ़ॉक्स का एक नया निर्माण जारी करने और शिपिंग करने की आवश्यकता होगी
  • एक वैध प्रमाणपत्र बनाएं और किसी तरह फ़ायरफ़ॉक्स को मौजूदा समाप्त हो चुके प्रमाणपत्र के बजाय इसे स्वीकार करने के लिए मनाएँ

हमने पहले पहले विकल्प का उपयोग करने का निर्णय लिया, जो काफी व्यावहारिक लग रहा था। दिन के अंत में, उन्होंने दूसरा सुधार (एक नया प्रमाणपत्र) जारी किया, जिसके बारे में हम बाद में बात करेंगे।

प्रमाणपत्र बदलना

जैसा कि मैंने ऊपर बताया, यह आवश्यक था:

  • एक नया वैध प्रमाणपत्र बनाएं
  • इसे फ़ायरफ़ॉक्स में दूरस्थ रूप से स्थापित करें

यह समझने के लिए कि यह क्यों काम करता है, आइए ऐड-ऑन सत्यापन प्रक्रिया पर करीब से नज़र डालें। ऐड-ऑन स्वयं फ़ाइलों के एक सेट के रूप में आता है, जिसमें हस्ताक्षर करने के लिए उपयोग किए जाने वाले प्रमाणपत्रों की एक श्रृंखला भी शामिल है। परिणामस्वरूप, ऐड-ऑन को सत्यापित किया जा सकता है यदि ब्राउज़र रूट प्रमाणपत्र जानता है, जो बिल्ड समय पर फ़ायरफ़ॉक्स में बनाया गया है। हालाँकि, जैसा कि हम पहले से ही जानते हैं, मध्यवर्ती प्रमाणपत्र समाप्त हो गया है, इसलिए ऐड-ऑन को सत्यापित करना असंभव है।

जब फ़ायरफ़ॉक्स किसी ऐड-ऑन को सत्यापित करने का प्रयास करता है, तो यह ऐड-ऑन के भीतर मौजूद प्रमाणपत्रों का उपयोग करने तक ही सीमित नहीं है। इसके बजाय, ब्राउज़र एक वैध प्रमाणपत्र श्रृंखला बनाने का प्रयास करता है, जो अंतिम प्रमाणपत्र से शुरू होता है और रूट तक पहुंचने तक जारी रहता है। पहले स्तर पर, हम अंतिम प्रमाणपत्र से शुरू करते हैं और फिर वह प्रमाणपत्र ढूंढते हैं जिसका विषय अंतिम प्रमाणपत्र (अर्थात् मध्यवर्ती प्रमाणपत्र) जारीकर्ता है। आमतौर पर यह मध्यवर्ती प्रमाणपत्र ऐड-ऑन के साथ प्रदान किया जाता है, लेकिन ब्राउज़र के भंडारण से कोई भी प्रमाणपत्र इस मध्यवर्ती प्रमाणपत्र के रूप में भी काम कर सकता है। यदि हम दूरस्थ रूप से प्रमाणपत्र स्टोर में एक नया वैध प्रमाणपत्र जोड़ सकते हैं, तो फ़ायरफ़ॉक्स इसका उपयोग करने का प्रयास करेगा। नया प्रमाणपत्र स्थापित करने से पहले और बाद की स्थिति.

नया प्रमाणपत्र स्थापित करने के बाद, प्रमाणपत्र श्रृंखला को मान्य करते समय फ़ायरफ़ॉक्स के पास दो विकल्प होंगे: पुराने अमान्य प्रमाणपत्र (जो काम नहीं करेगा) या नए वैध प्रमाणपत्र (जो काम करेगा) का उपयोग करें। यह महत्वपूर्ण है कि नए प्रमाणपत्र में पुराने प्रमाणपत्र के समान ही विषय का नाम और सार्वजनिक कुंजी हो, इसलिए अंतिम प्रमाणपत्र पर उसके हस्ताक्षर मान्य होंगे। फ़ायरफ़ॉक्स दोनों विकल्पों को आज़माने के लिए पर्याप्त स्मार्ट है जब तक कि उसे कोई ऐसा विकल्प न मिल जाए जो काम करता हो, इसलिए ऐड-ऑन का फिर से परीक्षण किया जाता है। ध्यान दें कि यह वही तर्क है जिसका उपयोग हम टीएलएस प्रमाणपत्रों को मान्य करने के लिए करते हैं।

लेखक का नोट: वेबपीकेआई से परिचित पाठक ध्यान देंगे कि क्रॉस-सर्टिफिकेट बिल्कुल उसी तरह से काम करते हैं।

इस सुधार के बारे में सबसे अच्छी बात यह है कि इसके लिए आपको मौजूदा ऐड-ऑन पर फिर से हस्ताक्षर करने की आवश्यकता नहीं है। जैसे ही ब्राउज़र को नया प्रमाणपत्र प्राप्त होगा, सभी ऐड-ऑन फिर से काम करेंगे। शेष चुनौती उपयोगकर्ताओं को नया प्रमाणपत्र वितरित करना है (स्वचालित रूप से और दूरस्थ रूप से), साथ ही फ़ायरफ़ॉक्स को अक्षम ऐड-ऑन की दोबारा जांच करना है।

नॉर्मंडी और अनुसंधान प्रणाली

विडंबना यह है कि इस समस्या को "सिस्टम" नामक एक विशेष ऐड-ऑन द्वारा हल किया जाता है। अनुसंधान करने के लिए, हमने नॉर्मंडी नामक एक प्रणाली विकसित की जो उपयोगकर्ताओं तक अनुसंधान पहुंचाती है। ये अध्ययन स्वचालित रूप से ब्राउज़र में किए जाते हैं, और फ़ायरफ़ॉक्स के आंतरिक एपीआई तक पहुंच बढ़ा दी है। अनुसंधान प्रमाणपत्र भंडार में नए प्रमाणपत्र जोड़ सकता है।

लेखक का नोट: हम किसी विशेष विशेषाधिकार वाला प्रमाणपत्र नहीं जोड़ रहे हैं; यह रूट प्रमाणपत्र द्वारा हस्ताक्षरित है, इसलिए फ़ायरफ़ॉक्स इस पर भरोसा करता है। हम इसे बस प्रमाणपत्रों के पूल में जोड़ते हैं जिनका उपयोग ब्राउज़र द्वारा किया जा सकता है।

तो समाधान एक अध्ययन बनाना है:

  • उपयोगकर्ताओं के लिए हमारे द्वारा बनाया गया नया प्रमाणपत्र स्थापित करना
  • ब्राउज़र को अक्षम ऐड-ऑन की दोबारा जांच करने के लिए मजबूर करना ताकि वे फिर से काम करें

"लेकिन रुकिए," आप कहते हैं, "ऐड-ऑन काम नहीं करते, मैं सिस्टम ऐड-ऑन कैसे लॉन्च कर सकता हूं?" आइए इस पर एक नए प्रमाणपत्र के साथ हस्ताक्षर करें!

यह सब एक साथ रखने पर... इसमें इतना समय क्यों लग रहा है?

तो, योजना: पुराने को बदलने के लिए एक नया प्रमाणपत्र जारी करें, एक सिस्टम ऐड-ऑन बनाएं और इसे नॉर्मंडी के माध्यम से उपयोगकर्ताओं के लिए इंस्टॉल करें। जैसा कि मैंने कहा, समस्याएं 4 मई को 4:00 बजे शुरू हुईं, और उसी दिन 12:44 बजे, 9 घंटे से भी कम समय के बाद, हमने नॉर्मंडी को एक समाधान भेजा। इसे सभी यूजर्स तक पहुंचने में 6-12 घंटे और लग गए। बिल्कुल भी बुरा नहीं है, लेकिन ट्विटर पर लोग पूछ रहे हैं कि हम तेजी से कार्रवाई क्यों नहीं कर सकते थे।

सबसे पहले, नया इंटरमीडिएट प्रमाणपत्र जारी करने में समय लगा। जैसा कि मैंने ऊपर बताया है, रूट प्रमाणपत्र की कुंजी हार्डवेयर सुरक्षा मॉड्यूल में ऑफ़लाइन संग्रहीत की जाती है। यह सुरक्षा के दृष्टिकोण से अच्छा है, क्योंकि रूट का उपयोग बहुत ही कम किया जाता है और इसे विश्वसनीय रूप से संरक्षित किया जाना चाहिए, लेकिन जब आपको किसी नए प्रमाणपत्र पर तत्काल हस्ताक्षर करने की आवश्यकता होती है तो यह थोड़ा असुविधाजनक होता है। हमारे एक इंजीनियर को एचएसएम भंडारण सुविधा की यात्रा करनी थी। फिर सही प्रमाणपत्र जारी करने के असफल प्रयास हुए, और प्रत्येक प्रयास में एक या दो घंटे का परीक्षण खर्च हुआ।

दूसरे, सिस्टम ऐड-ऑन के विकास में कुछ समय लगा। वैचारिक रूप से यह बहुत सरल है, लेकिन सरल कार्यक्रमों के लिए भी देखभाल की आवश्यकता होती है। हम यह सुनिश्चित करना चाहते थे कि हम स्थिति को और खराब न करें। उपयोगकर्ताओं को भेजे जाने से पहले अनुसंधान का परीक्षण किया जाना आवश्यक है। इसके अलावा, ऐड-ऑन पर हस्ताक्षर होना चाहिए, लेकिन हमारा ऐड-ऑन साइनिंग सिस्टम अक्षम था, इसलिए हमें एक समाधान ढूंढना पड़ा।

अंततः, एक बार जब हमारे पास शोध प्रस्तुत करने के लिए तैयार हो गया, तो तैनाती में समय लगा। ब्राउज़र हर 6 घंटे में नॉर्मंडी अपडेट की जाँच करता है। सभी कंप्यूटर हमेशा चालू और इंटरनेट से कनेक्टेड नहीं होते हैं, इसलिए उपयोगकर्ताओं तक समस्या फैलने में समय लगेगा।

अंतिम चरण

अनुसंधान को अधिकांश उपयोगकर्ताओं के लिए समस्या का समाधान करना चाहिए, लेकिन यह सभी के लिए उपलब्ध नहीं है। कुछ उपयोगकर्ताओं को एक विशेष दृष्टिकोण की आवश्यकता होती है:

  • वे उपयोगकर्ता जिन्होंने अनुसंधान या टेलीमेट्री अक्षम कर दी है
  • एंड्रॉइड संस्करण (फेनेक) के उपयोगकर्ता, जहां अनुसंधान बिल्कुल समर्थित नहीं है
  • उन उद्यमों में फ़ायरफ़ॉक्स ईएसआर के कस्टम बिल्ड के उपयोगकर्ता जहां टेलीमेट्री सक्षम नहीं की जा सकती
  • उपयोगकर्ता मिटएम प्रॉक्सी के पीछे बैठे हैं, क्योंकि हमारा ऐड-ऑन इंस्टॉलेशन सिस्टम कुंजी पिनिंग का उपयोग करता है, जो ऐसे प्रॉक्सी के साथ काम नहीं करता है
  • फ़ायरफ़ॉक्स के पुराने संस्करणों के उपयोगकर्ता जो अनुसंधान का समर्थन नहीं करते हैं

हम बाद की श्रेणी के उपयोगकर्ताओं के बारे में कुछ नहीं कर सकते - उन्हें अभी भी फ़ायरफ़ॉक्स के नए संस्करण में अपडेट करना चाहिए, क्योंकि पुराने संस्करण में गंभीर अप्रकाशित कमजोरियाँ हैं। हम जानते हैं कि कुछ लोग फ़ायरफ़ॉक्स के पुराने संस्करणों पर बने रहते हैं क्योंकि वे पुराने ऐड-ऑन चलाना चाहते हैं, लेकिन कई पुराने ऐड-ऑन पहले ही ब्राउज़र के नए संस्करणों में पोर्ट किए जा चुके हैं। अन्य उपयोगकर्ताओं के लिए, हमने एक पैच विकसित किया है जो एक नया प्रमाणपत्र स्थापित करेगा। इसे बगफिक्स रिलीज़ के रूप में रिलीज़ किया गया था (अनुवादक का नोट: फ़ायरफ़ॉक्स 66.0.5), इसलिए लोगों को यह मिल जाएगा - सबसे अधिक संभावना है कि यह पहले ही मिल चुका है - नियमित अपडेट चैनल के माध्यम से। यदि आप फ़ायरफ़ॉक्स ईएसआर के कस्टम बिल्ड का उपयोग कर रहे हैं, तो कृपया अपने अनुरक्षक से संपर्क करें।

हम समझते हैं कि यह आदर्श नहीं है. कुछ मामलों में, उपयोगकर्ताओं ने ऐड-ऑन डेटा खो दिया (उदाहरण के लिए, ऐड-ऑन डेटा मल्टी-अकाउंट कंटेनर).

इस दुष्प्रभाव को टाला नहीं जा सका, लेकिन हमारा मानना ​​है कि अल्पावधि में हमने अधिकांश उपयोगकर्ताओं के लिए सबसे अच्छा समाधान चुना है। दीर्घावधि में, हम अन्य, अधिक उन्नत वास्तुशिल्प दृष्टिकोणों की तलाश करेंगे।

पाठ

सबसे पहले, हमारी टीम ने समस्या का पता चलने के 12 घंटे से भी कम समय में समाधान तैयार करने और शिपिंग करने का अद्भुत काम किया। बैठकों में भाग लेने वाले व्यक्ति के रूप में, मैं कह सकता हूं कि इस कठिन परिस्थिति में लोगों ने बहुत मेहनत की और बहुत कम समय बर्बाद हुआ।

जाहिर है, इनमें से कुछ भी नहीं होना चाहिए था। ऐसी घटनाओं की संभावना को कम करने और उपचार को आसान बनाने के लिए हमारी प्रक्रियाओं को समायोजित करना स्पष्ट रूप से सार्थक है।

अगले सप्ताह हम एक आधिकारिक पोस्टमॉर्टम और उन परिवर्तनों की एक सूची प्रकाशित करेंगे जो हम करना चाहते हैं। अभी के लिए, मैं अपने विचार साझा करूंगा। सबसे पहले, संभावित टाइम बम की स्थिति पर नज़र रखने का एक बेहतर तरीका होना चाहिए। हमें यह सुनिश्चित करने की ज़रूरत है कि हम खुद को ऐसी स्थिति में न पाएं जहां उनमें से कोई एक अचानक काम करने लगे। हम अभी भी ब्योरे पर काम कर रहे हैं, लेकिन कम से कम ऐसी सभी चीजों को ध्यान में रखना जरूरी है।

दूसरा, हमें उपयोगकर्ताओं को तुरंत अपडेट देने के लिए एक तंत्र की आवश्यकता है, तब भी जब—विशेषकर जब—बाकी सब कुछ विफल हो जाए। यह बहुत अच्छा था कि हम "अनुसंधान" प्रणाली का उपयोग करने में सक्षम थे, लेकिन यह एक अपूर्ण उपकरण है और इसके कुछ अवांछित दुष्प्रभाव हैं। विशेष रूप से, हम जानते हैं कि कई उपयोगकर्ताओं के पास स्वचालित अपडेट चालू हैं, लेकिन वे शोध में भाग नहीं लेना चाहेंगे (मैं मानता हूं, मैंने उन्हें भी बंद कर दिया है!)। साथ ही, हमें उपयोगकर्ताओं को अपडेट भेजने का एक तरीका चाहिए, लेकिन आंतरिक तकनीकी कार्यान्वयन जो भी हो, उपयोगकर्ताओं को अपडेट (हॉट फिक्स समेत) की सदस्यता लेने में सक्षम होना चाहिए लेकिन बाकी सब चीजों से बाहर निकलना चाहिए। इसके अतिरिक्त, अद्यतन चैनल वर्तमान की तुलना में अधिक प्रतिक्रियाशील होना चाहिए। यहां तक ​​कि 6 मई को भी, ऐसे उपयोगकर्ता थे जिन्होंने फिक्स या नए संस्करण का लाभ नहीं उठाया। इस समस्या पर पहले ही काम किया जा चुका है, लेकिन जो हुआ उससे पता चला कि यह कितना महत्वपूर्ण है।

अंत में, हम यह सुनिश्चित करने के लिए ऐड-ऑन के सुरक्षा आर्किटेक्चर पर करीब से नज़र डालेंगे कि यह किसी भी चीज़ के टूटने के न्यूनतम जोखिम के साथ सही स्तर की सुरक्षा प्रदान करता है।

अगले सप्ताह हम जो कुछ हुआ उसके अधिक गहन विश्लेषण के परिणामों पर गौर करेंगे, लेकिन इस बीच मुझे ईमेल द्वारा प्रश्नों का उत्तर देने में खुशी होगी: [ईमेल संरक्षित]

स्रोत: linux.org.ru

एक टिप्पणी जोड़ें