‘इसे रोकने का कोई तरीका नहीं है,’ ऐसा कहता है वह एकमात्र package manager जहाँ ऐसी घटनाएँ नियमित रूप से होती हैं

• npm registry पर हुए supply chain हमले से लाखों enterprise apps और अरबों user records उजागर हो गए, लेकिन ecosystem ने इसे मानो टाला ही नहीं जा सकता था, ऐसे स्वीकार कर लिया
• Senior Frontend Engineer Mark Vance ने इस हकीकत पर तंज कसा कि एक string को uppercase करने के लिए भी unverified package की 40-स्तरीय nested dependency पर निर्भर रहना पड़ता है
• लंबे समय से उपेक्षित utility package के hijack हो जाने और दुनिया भर के production builds में crypto-miner inject हो जाने की स्थिति को मानो प्राकृतिक आपदा की तरह लिया जाता है
• Node.js ecosystem दुर्भावनापूर्ण remote code execution को एक अप्रत्याशित त्रासदी की तरह स्वीकार करता है, और DevOps टीमें AWS keys rotate करने में लगी रहती हैं
• Go, Rust, और native Web API ecosystems मजबूत standard library और cryptographic verification के जरिए third-party dependency घटाने वाले विपरीत उदाहरण के रूप में सामने आते हैं

---

npm supply chain attack पर व्यंग्य

• npm registry पर supply chain attack से लाखों corporate applications प्रभावित हुए और अरबों user records उजागर हुए, लेकिन JavaScript ecosystem के developers ने इसे इस तरह लिया मानो “इसे पूरी तरह टाला नहीं जा सकता था”
• Senior Frontend Engineer Mark Vance के अनुसार, एक single string को uppercase बनाने के लिए unverified package की 40-स्तरीय nested dependency tree पर निर्भर रहना आधुनिक web app development की कीमत जैसा है
• लंबे समय से छोड़े गए utility package के hijack होकर दुनिया भर के production builds में crypto-miner inject होने की स्थिति को प्राकृतिक आपदा जैसा माना जाता है
• Node.js ecosystem दुर्भावनापूर्ण remote code execution को अप्रत्याशित त्रासदी की तरह देखता है और AWS keys बदलने में व्यस्त DevOps टीमों के लिए “thoughts and prayers” भेजता है

दूसरे ecosystems और npm का अंतर

• Go, Rust, और native Web API ecosystems मजबूत standard library के कारण third-party code पर निर्भरता काफी कम करते हैं, और core toolchain में सख्त cryptographic verification शामिल करते हैं
• इन ecosystems में तुलना इस तरह की जाती है कि “कॉलेज छोड़ चुके किसी व्यक्ति के weekend project” ने आज global logistics infrastructure को नष्ट नहीं किया — और ऐसे मामलों की संख्या शून्य रही
• npm के spokesperson ने जोर देकर कहा कि दुर्भावनापूर्ण actors वाले संसार में इसे स्वीकार करना ही होगा, और इसे रोकने लायक registry policy या build sandbox guardrails मौजूद नहीं हैं
• npm registry को ऐसे open source registry के रूप में चित्रित किया गया है जो local machine पर arbitrary installation scripts को default रूप से चलाता है, जिससे spokesperson की बात और संरचनात्मक जोखिम एक-दूसरे से जुड़ जाते हैं
• अंत में पीड़ितों के लिए संवेदना व्यक्त करते हुए यह कहकर बात समाप्त होती है कि “कल सुबह होने वाले अगले अपरिहार्य breach” तक resilience बनाए रखनी होगी

[GN⁺]

Hacker News की राय

• cooldown के बारे में सबकी अपनी राय हो सकती है, लेकिन axios, tanstack समेत हाल की npm supply chain attacks में से काफ़ी को cooldown से टाला जा सकता था
  अगर आप Artifactory / Nexus इस्तेमाल करते हैं, तो संभव है कि cooldown पहले से ही हो, और न भी हो तो इसे सेट करना आसान है
  ज़्यादातर npm या PyPI compromise कुछ घंटों के भीतर हटा दिए गए, इसलिए cooldown का मतलब है “रिलीज़ हुए N दिन से कम पुराने पैकेज को ignore करो।” 1 दिन भी असरदार है, 3 दिन ठीक है, और 7 दिन थोड़ा ज़्यादा है लेकिन काम करता है
  इसे सेट करने के लिए आप default 1-day cooldown वाले latest pnpm का इस्तेमाल कर सकते हैं https://pnpm.io/supply-chain-security, या अगर एक ही बार में सब ठीक करना है तो https://depsguard.com इस्तेमाल कर सकते हैं, जो npm, pnpm, yarn, bun, uv, dependabot में cooldown और recommended settings जोड़ देता है। मैं इसका maintainer हूँ
  या फिर https://cooldowns.dev भी है, जो cooldown पर ज़्यादा focused है, और local settings में मदद करने वाली scripts भी हैं। सब open source हैं या free हैं
  अगर आप ~/.npmrc वगैरह सीधे edit कर सकते हैं, तो इसकी ज़रूरत नहीं, लेकिन आपके आसपास जिन लोगों को one-click solution चाहिए, उनके लिए यह अगला हमला टालने में मदद कर सकता है
  हाँ, जब किसी नई critical CVE को patch करना हो, तब cooldown को bypass करना पड़ेगा, और हर जगह उसके तरीके हैं। मेरे पास सटीक आँकड़े नहीं हैं, लेकिन पिछले कुछ हफ़्तों में जोखिम नई zero-day CVE से ज़्यादा software supply chain attacks से आता दिखा है

  • 7 दिन ज़्यादा लगते हैं, यह बात ही अजीब लगती है। जब तक कोई खास नई feature बहुत ज़रूरी न हो, नया project शुरू करते समय भी कुछ महीने पुराना dependency version आम तौर पर काफ़ी होना चाहिए
    नियमित dependency upgrades पर भी यही बात लागू होती है। हाँ, vulnerability response जैसी स्थिति में तुरंत upgrade करना पड़ सकता है, और तब developer जिस नए version को चाहता है उसे explicitly specify करने देना ठीक है
  • तो क्या इससे समस्या बस 7 दिन आगे खिसक नहीं जाएगी? मेरी समझ यह थी कि ऐसे incidents तब खत्म होते हैं जब कोई संक्रमित होता है और फिर उसे नोटिस करता है, न कि इसलिए कि बदलावों का audit करने वाली कोई सेना बैठी है
    अगर सब लोग 7-day cooldown लगा दें, तो क्या बस विस्फोट देर से नहीं होगा?
  • लगता है एक पंक्ति छूट गई है:

    Disclaimer: I maintain depsguard

  • मुझे पक्का नहीं कि cooldown प्रभावी होगा। किसी न किसी को cooldown bypass करके संभावित रूप से problematic release install करनी होगी और समस्या खोजनी होगी। अगर कोई ऐसा नहीं करता, तो बस समस्या 3/7/10/14 दिन टल जाती है
    यह लिखते-लिखते और सोच रहा हूँ तो भी, हाल के 10 दिनों में आई चीज़ें install न करने वाला 10-day cooldown मुझे फिर भी ठीक लगता है। बस इसे इकलौता mitigation मानकर नहीं चलना चाहिए
  • Linux distributions की तरह latest/stable/LTS वाले अलग distributions या channels क्यों नहीं बनाए जा सकते?

• यह जानने की जिज्ञासा है कि Go या Rust, Python/npm की तुलना में वास्तव में क्या guarantee देते हैं। कभी-कभी लगता है कि Python/npm बस ज़्यादा आकर्षक target हैं
  मैं तो धीरे-धीरे सभी third-party packages से बचने की कोशिश कर रहा हूँ

  • packages और namespaces का ownership कैसे दिया जाए, यह 100% package manager चलाने वाली संस्था पर निर्भर है
    Maven Central दशकों से मौजूद है, लेकिन namespace hijacking की घटनाएँ बहुत कम रही हैं
    ycombinator.com domain का ownership verify किए बिना आप groupId "com.ycombinator" के साथ package publish नहीं कर सकते। और एक बार publish हो जाने के बाद package 100% immutable होता है, चाहे उसमें malicious code ही क्यों न हो। हाँ, ऐसी libraries को हर जगह vulnerable के रूप में mark किया जाता है
    समझ नहीं आता कि NPM इतने लंबे समय में Maven Central जैसी safety rails क्यों नहीं अपना पाया
  • इस लेख की एक मुख्य बात यह है कि ज़्यादातर दूसरी लोकप्रिय languages के पास एक व्यापक standard library होती है। JS की standard library हैरान करने वाली तरह से छोटी है
    language के साथ shipped verified libraries का bundle होने के बजाय, applications को चीज़ें या तो खुद बनानी पड़ती हैं या third-party package repository से लानी पड़ती हैं। NIH से बचने की सीख लगातार दी गई है, इसलिए लोग package उठा लेते हैं
    यह अपने आप में ज़रूरी नहीं कि बुरा हो, लेकिन अक्सर ज़रूरत से ज़्यादा code खींच आता है। JS ecosystem छोटे modules को भी पसंद करता है, इसलिए बहुत सारे modules लगते हैं, और फिर सब उनके ऊपर और layers बनाते जाते हैं, जिससे dependency graph बहुत बड़ा हो जाता है। जानबूझकर हो या नहीं, समस्या पैदा होने की surface area बहुत बड़ी है
    दूसरी languages में बहुत कुछ built-in मिलता है। bugs और security issues वहाँ भी रहे हैं, लेकिन JS ecosystem में जो दिखता है उसके सामने वह बहुत कम है। external dependency graph काफ़ी छोटा होता है और core functionality trusted third parties से आती है
  • attackers वहीं जाते हैं जहाँ victims होते हैं। frontend लगभग single culture की तरह है जहाँ ज़्यादातर लोग NPM इस्तेमाल करते हैं, जबकि backend में यह बात कम है
    यह NPM के लिए कोई बहाना नहीं है, बल्कि उसके खिलाफ़ एक और point जोड़ता है
    यह भी कहा जा सकता है कि ऐसे हमले frontend और backend developers के अंतर को और साफ़ दिखाते हैं, लेकिन मैं वहाँ तक नहीं जाऊँगा
  • सच कहूँ तो Rust में भी लगभग वही supply chain attack pattern है। बस वह नया है और अभी बेहतर managed है। 10 साल इंतज़ार कर लीजिए
  • पिछली बार देखा था तो npm में publishing के लिए 2FA था, लेकिन cargo में नहीं। मुझे नहीं लगता cargo, npm से खास बेहतर है; बस वह उतना आकर्षक target नहीं है

• कई नौकरियों में हमें सभी developer machines पर सुरक्षित global npm settings install करनी पड़ीं, लोगों से उन्हें बंद न करने की गुज़ारिश करनी पड़ी, और MDM tools से verify भी करना पड़ा
  ज़्यादा सुरक्षित default settings बहुत पहले आ जानी चाहिए थीं

  • npm का इस्तेमाल ही मत कीजिए। ऐसा package manager इस्तेमाल कीजिए जो default में postinstall न चलाए, और switch करना हैरान कर देने जितना आसान है
  • मैं जानना चाहता हूँ कि सुरक्षित settings से आपका मतलब क्या है। अगर बात cooldown period या package allow/block lists enforce करने की है, तो सही तरीका है company-controlled repository सेट करना, जो upstream npm repository से fetch करे लेकिन आपकी policies enforce करे

• postinstall scripts के अस्तित्व का कोई वैध कारण नहीं होना चाहिए। npm team अब इतनी mature हो जानी चाहिए कि घोषित करे: “npm के version X से, ${today} से पहले publish हुए package versions के लिए ही postinstall scripts चलेंगी।”

  • मैंने हाल ही में कई popular packages की postinstall scripts audit कीं। उनमें से ज़्यादातर native binaries का इस्तेमाल करती हैं या उन्हें download करती हैं, platform compatibility detect करती हैं, Node को bootstrap करने देने के बजाय खुद wire-up करती हैं, और पुराने npm versions की समस्याओं को sidestep करती हैं
    वजह यह है कि esbuild जैसे dev toolchains compiled languages में लिखे जाते हैं और npm repositories के ज़रिए binaries के रूप में distribute किए जाते हैं। अगर आप latest Node/npm और आम modern OS/platform इस्तेमाल कर रहे हैं, तो वैध समस्याओं के बिना सभी postinstall scripts disable कर पाना संभव होना चाहिए
  • install scripts, package signing की तरह, ध्यान भटकाने वाला तत्व हैं। कौन-सी feature जोड़ी या हटाई जाती है, इससे इस package ecosystem की worm बनने की क्षमता पर बहुत फ़र्क नहीं पड़ता
    install किया गया npm code लगभग बिना किसी अपवाद के execute होता है
  • यह बात भी बहुत जायज़ नहीं लगती कि Rust packages build होते समय sandbox के बिना execute हो सकते हैं
  • इससे समस्या वास्तव में ठीक नहीं होती। package code build time और testing के दौरान भी execute होता है। दायरा थोड़ा कम हो सकता है, बस इतना ही
  • सावधानी से कहूँ तो, postinstall scripts लगभग पूरी तरह झूठा मुद्दा हैं। लोग इस बात से चौंकते हैं कि किसी और के control वाला code उनके कंप्यूटर पर चल सकता है और बुरा काम कर सकता है, और हाँ, कर सकता है
    लेकिन package के अंदर का सामान्य code भी ऐसा ही है। install के समय न चले तो भी अंततः उसमें से कुछ न कुछ चलेगा। वरना उसे dependency में शामिल ही क्यों किया जाता
    यह मान लेना कि postinstall scripts हटा देने से abuse rate पर एक क्षण से ज़्यादा असर पड़ेगा, इस बात का संकेत है कि समस्या को आखिर तक सोचकर नहीं देखा गया। दुर्भाग्य से यह समस्या मूल लेख के संकेत से कहीं ज़्यादा सूक्ष्म है
    यह “पंख गिराने वाला बटन लाइट स्विच के बगल में मत रखो” जैसी समस्या नहीं है, बल्कि असली बात यह है कि “किसी और का बुरा code मेरे कंप्यूटर पर चलना” और “किसी और का अच्छा code मेरे कंप्यूटर पर चलना” — इन दोनों में अंतर करने का कोई तरीका बेहद मेहनत वाले manual work के बिना नहीं है। और हम वही मेहनत बचाने के लिए तो दूसरों का code चला रहे हैं

• हर Node.js project की शुरुआत npm install से होती है, और अचानक अनचाहे 500 packages आ जाते हैं। उनमें से आधे तो कई सालों से छुए भी नहीं गए होते

• एक cultural problem भी है कि लोग जो चीज़ पहले से ठीक चल रही है, उसे भी जितना हो सके latest packages तक upgrade करना चाहते हैं। कई बार तो यह देखने के लिए changelog भी नहीं पढ़ते कि बदलाव लागू भी होता है या नहीं
  cooldown maintainers पर थोड़ी patience थोपने का एक तरीका है, और यह वाकई काम करता है

  • compliance requirements हों तो पुराने versions पर आने वाली CVE vulnerabilities के कारण update करना पड़ता है। उनमें से ज़्यादातर “regex DoS” जैसी लगभग नकली चीज़ें होती हैं, लेकिन procedure पूरा करना होता है, इसलिए update करना ही पड़ता है
  • और package owners भी कभी-कभी ऐसी चीज़ें update करते हैं जिन्हें update करने की ज़रूरत नहीं होती, सिर्फ़ इसलिए कि वे पुराने और छोड़े हुए न दिखें
    Lisp packages 15 साल तक बिना बदलाव के अच्छे से चल सकते हैं, लेकिन JS packages को maintenance न होने पर मानो आपदा समझा जाता है। जबकि वे 15 साल पहले ही complete हो चुके होते हैं, फिर भी npm और GitHub पर actively maintained दिखने के लिए लोग कुछ भी न जोड़ते हुए, या कभी-कभी breaking changes डालकर भी version bump कर देते हैं। फिर सब कुछ update होने लगता है

• 7-day cooldown कम मेहनत में लग जाने वाला अस्थायी जुगाड़ लगता है। असली समाधान शायद reproducible builds और signed attestations होंगे, लेकिन ज़्यादातर teams तब तक उसकी लागत नहीं चुकाएँगी जब तक वे खुद शिकार न बन जाएँ

• यह किसी Onion article जैसा लगता है

  residents of the Node.js ecosystem stood unified in their belief that the malicious remote-code execution was a completely unpredictable tragedy
  क्या सच में कोई इस दावे पर यक़ीन करता है? इसके खिलाफ़ उदाहरण बहुत रहे हैं
  ecosystem की नाकामी पर यह अच्छी चोट करने वाला satire है, लेकिन आखिरकार यह मनोरंजन ही है। शायद marketers के लिए अपना सामान आगे करने का मौका भी बन जाता है। जैसे depsguard के maintainer ने अपनी post में यह बात हटाई, फिर जोड़ी, फिर हटाई। यह लिखते समय वही post सबसे ऊपर है

  • सही, यह बड़े पैमाने पर गोलीबारी पर The Onion के लेख से निकला हुआ format है: https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...

• यह लिंक Xe Iaso के लंबे समय से चलते आ रहे joke का साफ़ तौर पर AI से धुला हुआ version है। अफ़सोस
  https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024...
  https://news.ycombinator.com/item?id=40438408

  • दोनों ही The Onion की पुरानी recurring article series की parody हैं.[0]
    [0]: https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
  • यह phrasing format कम-से-कम 2014 के The Onion तक जाता है
    https://en.wikipedia.org/wiki/%27No_Way_to_Prevent_This,%27_...
  • सच कहूँ तो मैं भी कुछ समय से इसी तरह की चीज़ बनाने की सोच रहा था, लेकिन मौजूदा generator में ठीक 69 lines of code हैं या नहीं, यह ज़रूर जाँचना होगा: https://github.com/Xe/site/blob/main/cmd/no-way-to-prevent-t...