- सप्लाई चेन हमला वह तरीका है जिसमें ओपन सोर्स कोड में malicious update छिपकर आ जाता है, और Obsidian इसे कम से कम करने के लिए बाहरी dependencies को ही घटाने की रणनीति अपनाता है
- ऐप की अधिकांश सुविधाओं को सीधे खुद implement किया जाता है, या ज़रूरत पड़ने पर fork किए गए code को अपने codebase में शामिल करके प्रबंधित किया जाता है
- ज़रूरी बड़े libraries (pdf.js, Mermaid, MathJax आदि) के लिए version pinning के ज़रिए सुरक्षा सुनिश्चित की जाती है, और updates केवल security patch होने पर ही सावधानी से किए जाते हैं
- सभी dependencies को lockfile से pin किया जाता है, और postinstall scripts नहीं चलाए जाते, ताकि installation के समय arbitrary code execution को रोका जा सके
- इस तरह की सावधानीपूर्ण update प्रक्रिया और time-delay रणनीति के ज़रिए Obsidian संभावित खतरों का सामना समुदाय द्वारा उन्हें पहचानने से पहले कर सकता है
सप्लाई चेन हमला क्या है
- सप्लाई चेन हमला वह तरीका है जिसमें ओपन सोर्स ecosystem में malicious update, distributed code में छिपकर प्रवेश कर जाता है
- चूँकि बहुत-से apps ओपन सोर्स code का उपयोग करते हैं, एक malicious update लहर की तरह फैलकर कई apps को प्रभावित कर सकता है
- Obsidian dependencies को न्यूनतम रखने की रणनीति के माध्यम से इस attack surface को घटाता है और ऐप को अधिक सुरक्षित तरीके से डिज़ाइन करता है
dependencies को न्यूनतम रखने की रणनीति: Less is Safer
- Obsidian अपनी श्रेणी के अन्य apps की तुलना में बहुत कम external libraries पर निर्भर करता है
- मुख्य सुविधाएँ (जैसे Bases, Canvas) external library अपनाने के बजाय in-house implement की जाती हैं
- इससे चलने वाले code पर पूर्ण नियंत्रण हासिल किया जा सकता है
- छोटे utility functions लगभग हमेशा development team खुद implement करती है
- मध्यम आकार के modules को, यदि license अनुमति दे, fork करके codebase में शामिल किया जाता है
- बड़े libraries (pdf.js, Mermaid, MathJax आदि) को validated versions पर pin करके शामिल किया जाता है, और केवल महत्वपूर्ण security issue मिलने पर ही न्यूनतम upgrade किया जाता है
- सभी बाहरी बदलावों की विस्तार से समीक्षा की जाती है और कठोर testing प्रक्रिया अपनाई जाती है
- इस तरीके से sub-dependencies की संख्या भी न्यूनतम रहती है, जिससे malicious code के प्रवेश का प्राथमिक जोखिम ही कम हो जाता है
वास्तव में ऐप में शामिल होने वाले तत्व
- उपयोगकर्ता जिस वास्तविक ऐप को चलाते हैं, उसमें Electron, CodeMirror, moment.js जैसे बहुत कम packages ही शामिल होते हैं
- बाकी development tools केवल app build प्रक्रिया में उपयोग होते हैं और अंतिम उपयोगकर्ता तक नहीं पहुँचते
version pinning और lockfile प्रबंधन
- सभी external dependencies का प्रबंधन कड़े version pinning और lockfile commit के माध्यम से किया जाता है
- इससे installation हमेशा reproducible रहती है और बदलावों को track करना आसान होता है
- postinstall scripts न चलाने की नीति के माध्यम से installation के दौरान arbitrary code execution की संभावना को मूल रूप से रोका जाता है
धीमी और सावधानीपूर्ण update प्रक्रिया
- जब dependency upgrade की ज़रूरत होती है, तब नीचे दी गई व्यवस्थित review प्रक्रिया अपनाई जाती है
- changelog की हर पंक्ति को बारीकी से review करना
- नए version में जोड़ी गई sub-dependencies की जाँच करना
- यदि बदलाव बड़े हों या जोखिम हो, तो upstream source के साथ diff को सीधे देखना
- मुख्य paths और platforms पर automated/manual tests चलाना
- इन सभी चरणों के पास होने के बाद ही lockfile commit करना
- अधिकांश dependencies को बार-बार बदलने की ज़रूरत नहीं होती, इसलिए update की आवृत्ति भी कम रहती है
- नए external code को शामिल करना नई dependency अपनाने के समान स्तर की समीक्षा और प्रबंधन के साथ किया जाता है
स्थिरता के लिए "समय का बफ़र": Time is a buffer
- विभिन्न upgrades को तुरंत deploy नहीं किया जाता, बल्कि कुछ समय के लिए रोका जाता है
- इस अवधि में ओपन सोर्स community और security researchers को malicious versions का पता लगाने का अवसर मिल जाता है
- वास्तविक deployment के समय तक समस्या के सामने आ जाने की संभावना अधिक होती है, इसलिए जोखिम कम करने में यह प्रभावी है
निष्कर्ष
- केवल एक सुरक्षा उपाय से सप्लाई चेन हमले के जोखिम को पूरी तरह समाप्त नहीं किया जा सकता
- लेकिन Obsidian dependencies को न्यूनतम रखना, shallow graph, version pinning, postinstall पर रोक, और review-केंद्रित धीमे updates को साथ लेकर जोखिम को काफ़ी हद तक घटाता है
- इन प्रक्रियाओं के ज़रिए code के उपयोगकर्ता तक पहुँचने से पहले जोखिम पहचानने के लिए पर्याप्त समय भी मिल जाता है
- Obsidian का पूरा security approach और पुराने security audits का विवरण उसकी आधिकारिक security page पर देखा जा सकता है
1 टिप्पणियां
Hacker News राय
कई लोगों की राय है कि ज़्यादातर यूज़र इस बात को नज़रअंदाज़ करते हैं कि Obsidian में third-party community plugins इस्तेमाल होते हैं; वास्तव में Obsidian का plugin security model बहुत कमजोर है, क्योंकि plugins को vault के भीतर की सभी files तक access मिल जाता है। अगर Obsidian ने खुद ज़्यादा features built-in देने की कोशिश की होती तो security risk कम हो सकता था। या फिर browser extensions की तरह plugins किन permissions का उपयोग करते हैं, इसे स्पष्ट दिखाया जाए और बिना अनुमति वाले permission access को block किया जाए, तो भी सुधार हो सकता है। यह सब “third-party dependencies कम हैं” वाली दलील से कहीं ज़्यादा वास्तविक user security देता।
पहले software जगत के कुछ लोग इस बारे में बात करते थे कि video game design के ideas दूसरे सामान्य software में कैसे आते हैं, लेकिन अब यह लगभग सुनने को नहीं मिलता। अगर Blizzard जैसी पुरानी game companies के core लोग World of Warcraft के plugin system के शुरुआती 10 साल कैसे काम करते थे, उसकी समस्याएँ क्या थीं, और security कैसे मजबूत की गई—इस पर कोई किताब लिखें, तो पूरे software ecosystem को बहुत फायदा होगा। कई projects के plugin systems ढीले-ढाले और अधकचरे लगते हैं।
Obsidian plugins को सिर्फ vault के भीतर की files ही नहीं, बल्कि कंप्यूटर की सभी files तक access मिल सकता है। मैंने पहले Discord पर यह बात उठाई थी, लेकिन उसे नज़रअंदाज़ कर दिया गया।
यह Arch Linux जैसा लगता है। AUR में software को सीधे manage करते समय engineers के लिए भी security संभालना मुश्किल होता है; आम users से security की ज़िम्मेदारी लेने की उम्मीद करना अव्यावहारिक है।
मुझे लगता है कि जल्द ही किसी Obsidian plugin से data exfiltration का मामला सामने आएगा। तब टीम security controls जोड़ेगी। कम से कम verified publisher system तो होना ही चाहिए।
मैं commercial रूप से Obsidian plugins बना रहा हूँ, और चाहता हूँ कि एक निश्चित स्तर से ऊपर के plugins के लिए अधिक सख्त review process हो। Arch Linux के AUR की तरह एक community-managed repository और एक अधिक कड़े review वाली repository—ये दो स्तर plugin review की speed और security दोनों सुधार सकते हैं।
इसमें कहा गया है कि “supply-chain attack वह है जिसमें बहुत-सी apps में इस्तेमाल होने वाले open source code में malicious update छिपकर आ जाए”, लेकिन open source (FOSS) न होने वाला कोई भी source code हमला झेल सकता है। यह धारणा कि FOSS अनिवार्य रूप से ज़्यादा कमजोर है, समस्याग्रस्त है।
“installation के दौरान postinstall scripts नहीं चलाते” वाली policy का इरादा अच्छा है, लेकिन अगर package पहले ही compromise हो चुका हो, तो postinstall छोड़ देने से बाकी code सुरक्षित नहीं हो जाता। और अगर package सही हो, तो postinstall वैध installation में मदद भी कर सकता है। वास्तविक incidents supply-chain attacks की तुलना में सामान्य vulnerability patches में ज़्यादा होते हैं, इसलिए updates को रोकना उल्टा risk बढ़ा सकता है।
आजकल security scanning आमतौर पर install होने के बाद (post install) होती है। installation के दौरान कुछ भी execute न होने देना बेहतर है। उम्मीद है कि आगे install चरण में scanning या restrictions जैसी सुविधाएँ ज़्यादा आम होंगी। कुछ commercial tools में यह है, लेकिन अभी व्यापक नहीं है।
फिर भी build machines की सुरक्षा के लिए इसका महत्व है। कम से कम मुझे यह चिंता नहीं करनी पड़ती कि मेरी ढेर सारी dependencies से कोई arbitrary script चल रही होगी।
यूज़र्स को distribute किए जाने वाले हर code की ज़िम्मेदारी developer की होती है। अगर dependencies pin नहीं की गई हैं, तो यह “इंटरनेट से random code download करके किस्मत पर भरोसा करने” जैसा है।
dependencies pin करने से बाद के security patches छूट सकते हैं। यह भी risk है, इसलिए यह जानने के लिए कोई system ज़रूर होना चाहिए कि नया security patch कब आया। फिर या तो उस patch को backport करना होगा या नई version पर update करना होगा।
pinned dependencies भी अपने भीतर दूसरी dependencies रखती हैं, इसलिए आखिरकार यह हमेशा “random code download करके उम्मीद करने” जैसा ही ढाँचा रहता है। खासकर Electron-based apps में तो सचमुच बहुत बड़ी मात्रा में code साथ आता है।
हाल में मैं एक सलाह बार-बार देख रहा हूँ कि patch release आने पर भी dependencies update मत करो, और यह मुझे समझ नहीं आता। update न करने से malware installation का खतरा कम हो सकता है, लेकिन आमतौर पर patches security सुधार के लिए होते हैं। क्या latest patches लागू न करना वाकई समझदारी है?
असली बात यह समझना है कि patch क्यों लगाया जा रहा है और उसमें क्या बदला है। सभी source code पढ़ने का समय नहीं होता, इसलिए मुख्य tools और services (जैसे Npm Audit) से vulnerability summary देखी जाती है। मैं बिना बहुत ज़रूरत updates टालने की strategy अपनाता हूँ, क्योंकि updates attack vector भी होते हैं और bugs का बड़ा कारण भी। लेकिन मैं नियमित रूप से यह ज़रूर जांचता हूँ कि किन vulnerabilities के संपर्क में हूँ। अगर vulnerability किसी ऐसी feature में है जिसे मैं उपयोग नहीं करता, तो update टाल सकता हूँ। सच में गंभीर flaws पर ही तुरंत update करता हूँ। security एक active और ongoing process है, और प्रतिक्रिया संगठन की risk tolerance पर निर्भर होनी चाहिए। सिर्फ “हमेशा update करो” या “कभी update मत करो”—इनमें से कोई भी अकेला जवाब नहीं है।
आजकल जब भी मैं Z-WaveJS UI update करता हूँ, dependency updates फिर सामने आ जाते हैं। इस असंतोषजनक pattern की वजह से मैं खुद जांच करता हूँ। आज के समय में हर कोई dependencies पर निर्भर है, इसलिए “इसका अंत नहीं है”; एक बार auto-update भी जोखिम भरा हो सकता है।
updates में हमेशा सुधार या गिरावट, दोनों का risk रहता है, और npm ecosystem (जिसमें Obsidian आता है) में यह risk बहुत ज़्यादा है। npm में malicious packages हटाने के लिए human intervention चाहिए, इसलिए कार्रवाई धीमी होती है। update जानबूझकर देर से करने से कुछ हद तक बचाव हो सकता है।
हाल में patch release के तुरंत बाद थोड़ा इंतज़ार करके install करना एक चलन बन गया है। आजकल incidents कई बार कुछ घंटों में पकड़ लिए जाते हैं। कई कंपनियाँ npm की निगरानी करती हैं और security business भी करती हैं। pnpm में यह configure किया जा सकता है कि package publish होने के X मिनट बाद ही install हो। मैं कम से कम 24 घंटे इंतज़ार करता हूँ pnpm minimumreleaseage setting
दो हफ्ते पहले मेरे package पर जो हमला हुआ, वह patch release को निशाना बनाकर किया गया था। वह postinstall script नहीं था। automated scanning इसे जल्दी पकड़ लेती है, इसलिए अब यह समस्या पहले जितनी उभरकर नहीं आती। package में vulnerability मिलते ही तुरंत alert आ जाता है और बात स्पष्ट हो जाती है। version ranges का उपयोग supply-chain attacks से निपटने के लिहाज़ से सबसे खराब है।
यह कहना मुश्किल है कि सिर्फ Electron, CodeMirror, और moment.js शामिल होने से package छोटा है। Electron webview-आधारित और बहुत जटिल software है, और moment.js के लिए पहले से बेहतर APIs मौजूद हैं। Obsidian की dependency management मुझे किसी विशेष security policy से ज़्यादा सिर्फ न्यूनतम स्तर का मानक लगती है। फिर भी यह अच्छी बात है कि वे नियमित security audits करते हैं।
मैं Obsidian के बजाय दूसरे apps इस्तेमाल करता रहा हूँ, लेकिन अब Obsidian में भी दिलचस्पी होने लगी है। यह Electron app है, इसलिए resources ज़्यादा लेता है और native नहीं है, इसलिए JS को लेकर हमेशा थोड़ी असहजता रहती है। पता नहीं मैं ज़्यादा पुराने खयाल का हूँ या नहीं।
JavaScript बहुत सुरक्षित भाषा है। web browser दुनिया भर में JavaScript को सुरक्षित तरीके से चलाने का सफल उदाहरण हैं; हर website दूसरी की data नहीं पढ़ सकती। Electron भी JavaScript को v8 engine में sandbox करता है। जब तक user input code execute करने से बचा जाए, यह काफी सुरक्षित है। supply-chain attack की समस्या npm की है, JS भाषा की नहीं। package publish करते समय npm की ज़िम्मेदारी है कि security policies अधिक सख्ती से लागू करे।
JavaScript किसी भी मापदंड से देखें, दुनिया की सबसे ज़्यादा इस्तेमाल होने वाली भाषाओं में से एक है। यह लगभग हर computer और smartphone पर चलती है। इसलिए security issues भी इसमें ज़्यादा बार मिलते हैं। native apps अपने-आप ज़्यादा सुरक्षित होते हैं, ऐसा कोई ठोस आधार नहीं है।
Electron apps अपने-आप में समस्या नहीं हैं। GitHub, VS Code, Slack, Discord, Postman—सब Electron-based हैं। मैं अक्सर पूछना चाहता हूँ: markdown note app में आखिर ऐसा कौन-सा performance-heavy काम हो रहा है? क्या लोग सचमुच इतने पुराने laptop पर text-only mode में Lynx browser से नोट्स देखते हैं?
मुझे Electron खास पसंद नहीं है (इसलिए tauri पसंद है), लेकिन Obsidian खुद बहुत शानदार है, इसलिए सिर्फ Electron की वजह से इसे नज़रअंदाज़ नहीं करना चाहिए। MCP के साथ जोड़कर इसे personal knowledge base की तरह भी बढ़िया इस्तेमाल किया जा सकता है, इसलिए मैं इसकी सिफारिश करता हूँ।
Electron भारी तो है। PC पर यह बड़ी समस्या नहीं बनता, लेकिन mobile पर जब notes हज़ारों में हो जाएँ, तो plugins के बिना भी app start होने में देर लगती है। users तेज़ capture के लिए plugins या दूसरे apps का सहारा लेते हैं, लेकिन इच्छा यही है कि कोई हल्का native Obsidian होता।
Obsidian Electron-based है, और इसी प्रकृति के कारण इसमें भारीपन और security vulnerabilities का risk जुड़ा रहता है।
मैं Emacs और Org-Roam इस्तेमाल करता हूँ, और इसे बिना network connection वाले VM (Qubes OS के Qube) में चलाता हूँ। Emacs में चलने वाले हर code की मैं खुद समीक्षा नहीं कर सकता।
अगर आप native app चाहते हैं और supply-chain risk भी कम करना चाहते हैं, तो GTK-based और प्रमुख Linux distributions में packaged Zim wiki एक विकल्प है Zim wiki देखें