AUR पैकेज infostealer और rootkit से संक्रमित हुए

 (discourse.ifin.network)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AUR पैकेज रिपॉज़िटरी ऐसी संरचना है जहाँ unmaintained पैकेजों को कोई भी अपना सकता है और PKGBUILD व संबंधित फ़ाइलों में बदलाव जमा कर सकता है; इस घटना में 408 से अधिक पैकेज संक्रमित होने के संकेत मिले हैं
  • एक नए AUR पैकेज maintainer ने भरोसेमंद maintainer का रूप धरकर पैकेज अपनाए, और अन्य AUR maintainers ने संक्रमित पैकेजों को हटाने का काम शुरू किया
  • शुरुआती संक्रमित पैकेजों में preinstall स्क्रिप्ट को बदलकर npm चलाया गया ताकि malicious payload atomic-lockfile इंस्टॉल हो सके
  • बाद की संक्रमण लहर में Bun के ज़रिए malicious js-digest इंस्टॉल किया गया, जिसे NPM ने हटा दिया
  • ज़्यादातर पैकेज कम इस्तेमाल होते हैं, लेकिन दायरा बड़ा है, और infostealer व्यवहार के साथ eBPF rootkit तक शामिल होने के कारण यह एक अहम supply chain attack है

घटना की स्थिति

  • क्या हुआ

    • एक नए AUR पैकेज maintainer ने भरोसेमंद maintainer का रूप धरकर 408 से अधिक पैकेज अपनाए और उन्हें संक्रमित किया होने के संकेत हैं
    • compromise की रिपोर्ट आने के बाद अन्य AUR maintainers ने संक्रमित पैकेजों को हटाने का काम शुरू किया
    • 2026-06-12T17:30:00Z तक AUR maintainers ने रिपोर्ट किया कि सभी malicious commits हटा दिए गए हैं
    • AUR maintainers ने पैकेज adoption फीचर सहित कुछ सुविधाओं पर नियंत्रण और सीमाएँ लागू करने का फैसला किया है
    • Arch Linux ने Active AUR malicious packages incident सूचना जारी की

  • malicious dependencies

    • हमले में कम से कम दो अलग malicious dependencies शामिल थीं
    • शुरुआती प्रभावित पैकेजों को इस तरह संशोधित किया गया कि preinstall स्क्रिप्ट npm का उपयोग कर malicious payload atomic-lockfile पैकेज इंस्टॉल करे
    • premake-git पैकेज में इस बदलाव का उदाहरण commit है
    • बाद की संक्रमण लहर में Bun का उपयोग कर malicious js-digest इंस्टॉल किया गया, और NPM ने js-digest को हटा दिया
    • हमले का विश्लेषण Preliminary analysis of AUR malware में विस्तार से दिया गया है

प्रतिक्रिया और compromise indicators

  • सुझाए गए कदम

    • यदि आप Arch का उपयोग नहीं करते, तो इस AUR पैकेज compromise का आप पर सीधा असर नहीं है
    • Arch उपयोगकर्ताओं को प्रभावित पैकेजों की सूची की समीक्षा करनी चाहिए और exposure जाँचने वाली स्क्रिप्ट से अपने सिस्टम की जाँच करनी चाहिए
    • मूल लेख से जुड़ा aur_check.sh पुराना संस्करण है; नवीनतम जाँच के लिए संबंधित Gist के निर्देशों का पालन करना चाहिए
    • यदि compromise indicators मिलते हैं, तो उचित forensic जाँच के लिए सिस्टम को सुरक्षित रूप से संरक्षित रखना चाहिए
    • यदि संक्रमित पैकेज मिलें, तो सामान्य incident response प्रक्रिया अपनानी चाहिए, सभी credentials बदलने चाहिए और Arch को दोबारा इंस्टॉल करने पर विचार करना चाहिए
    • rootkit की संभावना के कारण सिस्टम की विश्वसनीयता की गारंटी नहीं दी जा सकती
    • सभी उपयोगकर्ताओं को नेटवर्क पर outbound Tor ट्रैफ़िक ब्लॉक करने के कदम उठाने चाहिए

  • compromise indicators

    • js-digest में शामिल malicious Linux executable का SHA256 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316 है
    • bpftool map list से संदिग्ध eBPF Maps का पता लगाया जा सकता है
    • संदिग्ध map नामों में hidden_pids, hidden_names, hidden_inodes शामिल हैं

  • अतिरिक्त पुष्टि योग्य बिंदु

    • malicious commits किसी मौजूदा maintainer अकाउंट ने नहीं किए; बल्कि ज्ञात maintainer अकाउंट की नकल की गई थी
    • ज़्यादातर पैकेज कम इस्तेमाल होते हैं, लेकिन 408 से अधिक पैकेजों तक फैला संक्रमण दायरा बड़ा है
    • infostealer व्यवहार के साथ eBPF rootkit तक शामिल होना इस supply chain attack को दुर्लभ बनाता है
    • Socket.dev पर atomic-lockfile पेज इस malicious NPM पैकेज के 134 downloads दिखाता है
    • NPM पैकेज को उपयोगकर्ता herbsobering maintain करता है
    • GitHub पर herbsobering यूज़रनेम खोजने पर reverse shell/proxy टूल जैसा दिखने वाला एकल कंटेनर इमेज herbsobering430 मिलता है
    • AUR पैकेज रिपॉज़िटरी में यदि कोई पैकेज unmaintained के रूप में चिह्नित हो, तो कोई भी उसे adopt कर सकता है और PKGBUILD व संबंधित फ़ाइलों में बदलाव जमा कर सकता है
    • छोड़े गए पैकेजों को अपने-आप ढूँढकर adopt करना असामान्य नहीं है, और संबंधित पृष्ठभूमि Mastodon thread में है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • यह मानना होगा कि AUR सिर्फ़ यूज़र-निर्मित PKGBUILD का एक संग्रह है
    AUR से इंस्टॉल किए जाने वाले हर PKGBUILD के source की समीक्षा करना ज़रूरी है, और updates भी इसका अपवाद नहीं हैं। यह 10 साल से भी ज़्यादा समय से लगातार चर्चा में रहा एक मूलभूत सिद्धांत है, और यही वजह है कि yay जैसे कोई आधिकारिक AUR helper मौजूद नहीं हैं
    Arch Linux के elitist होने की शिकायतें बहुत हैं, लेकिन व्यवहारिक रूप से यह उन लोगों के लिए एक distro है जो जानते हैं कि वे क्या कर रहे हैं और हर कदम पर हाथ पकड़कर चलाने की उम्मीद नहीं रखते। इसका मतलब यह भी है कि अगर आपने कोई random AUR package इंस्टॉल करके अपना system खराब कर लिया या compromise करवा लिया, तो उसकी ज़िम्मेदारी आपकी है
    हालाँकि, शायद वह समय खत्म हो रहा है जब किसी को भी AUR package takeover करने दिया जाए। हर बार प्रभावित packages को rollback करने की लागत ही बहुत ज़्यादा है। विकल्प के तौर पर हर takeover request की समीक्षा करना भी बहुत बोझिल है, और यह भी तय नहीं कि हर बार उससे मदद ही मिलेगी

    • अगर AUR से इंस्टॉल किए जाने वाले हर PKGBUILD source की समीक्षा करनी चाहिए, तो क्या यही बात browser extensions, VSCode extensions, NuGet packages, Cargo crates, Python packages, npm packages आदि पर भी समान रूप से लागू नहीं होती?
      मेरा मानना है कि हाँ, जब तक आप उन्हें ऐसे स्थान पर नहीं चला रहे जहाँ internet access न हो, या वे सिर्फ़ ऐसी चीज़ों तक पहुँच रखते हों जिनके public हो जाने से फ़र्क नहीं पड़ता
      AUR शायद ऐसा न हो, लेकिन दूसरे ecosystems को सैद्धांतिक रूप से permission model या sandboxing से बेहतर बनाया जा सकता है। browser extensions में ऐसे विकल्प पहले से मौजूद हैं, लेकिन “सामान्य” यूज़र उनका शायद ही इस्तेमाल करते हैं
      दुर्भाग्य से 99.99% लोग हर चीज़ की समीक्षा नहीं कर सकते या उनके पास उसका समय नहीं है। trusted maintainers वाले distro packages, या permissions और कुछ हद तक review वाले iOS App Store जैसी जगहें सबसे सुरक्षित लगती हैं
    • यह वास्तव में कोई समाधान नहीं लगता। ऐसे हमलों का सामान्य पैटर्न dependency chain में कहीं payload छिपाना रहा है
      इस बार मामला थोड़ा अलग है क्योंकि PKGBUILD के अंदर बहुत ही ढीलेपन से npm install किया गया है। अब AUR के बाहर लगभग हर package repository में भी यही समस्या है, और पूरी dependency chain का हाथ से audit करना व्यावहारिक नहीं है
      बेशक, मेरे पास भी कोई समाधान नहीं है
    • यह मानना कि यूज़र्स का थोड़ा-सा हिस्सा भी वास्तव में ऐसा करता है, हक़ीक़त से बहुत दूर की सोच है
    • AUR का यूज़र-निर्मित PKGBUILD का संग्रह होना, PyPI ecosystem, npm, और पूरे Docker Hub से कितना अलग है, यह स्पष्ट नहीं है
      लोग SELinux बंद कर देते हैं, --privileged seccomp और AppArmor को निष्क्रिय कर देता है, और sandbox escape CVE भी मौजूद हैं
    • किसी को भी AUR package takeover करने देना शुरू से ही नहीं होना चाहिए था
      अंततः मैं चाहता हूँ कि संरचना username/packagename-bin|git जैसी हो। तब लोगों के लिए यह कहीं अधिक स्पष्ट होगा कि वे वास्तव में क्या और किससे इंस्टॉल कर रहे हैं

  • यह campaign अभी भी जारी है। मुझे अभी-अभी मेल मिला कि मेरा एक पुराना package takeover कर लिया गया है; वह कई सालों से काम नहीं कर रहा था और कुछ समय से orphan package था। takeover के तुरंत बाद malicious commit push किया गया
    अब लगता है कि वे npm की जगह bun का उपयोग कर रहे हैं, इसलिए npm-आधारित workaround शायद प्रभावी न रहे
    https://aur.archlinux.org/cgit/aur.git/commit/?h=toggldeskto...

    • अब तो लगने लगा है कि orphan package takeover की अवधारणा ही टूट चुकी है, और शायद इसे पूरी तरह हटा देना चाहिए
      यह असुविधाजनक होगा, लेकिन शायद बेहतर यह हो कि किसी और को छोड़े गए package का takeover करने देने के बजाय AUR नए submission को अनिवार्य करे, और एक निश्चित समय के बाद orphan packages को नियमित रूप से delete करता रहे
    • मुझे भी अभी notification मिला कि जिन AUR packages में से एक को मैं track कर रहा था, वह orphan package होने के कारण किसी अनजान व्यक्ति को सौंप दिया गया

  • AUR से कुछ इंस्टॉल करते समय सावधान रहना तो स्वाभाविक है, और पहले भी संदिग्ध packages — जैसे गलत तरीके से build किए गए या गलत तरह से package किए गए — हमेशा रहे हैं, लेकिन सक्रिय malicious injection देखना चिंताजनक है
    मुझे लगता है कि AUR में दो बड़ी समस्याएँ हैं। पहली, यह open source के उस कुछ अधिक egalitarian दौर का अवशेष है जहाँ third-party code पर आम तौर पर भरोसा किया जा सकता था। दूसरी, यह कि orphan packages को कोई भी उनके मौजूदा record और verification history के साथ takeover कर सकता है
    पहला दौर अब बीत चुका है, और दूसरी समस्या को AUR accounts पर अधिक सख्त नियंत्रण या AUR helpers में अतिरिक्त सुरक्षा उपाय जोड़कर कम किया जा सकता है। उदाहरण के लिए, अगर किसी package का मालिक हाल ही में बदला हो, तो बहुत बड़ा डरावना warning दिखाया जाए। फिर भी कुछ लोग बस y दबाकर आगे बढ़ जाएँगे, लेकिन कुछ न होने से यह बेहतर है
    या फिर AUR helpers से पूरी तरह बचकर, ज़रूरी packages को सीधे PKGBUILD में review करके build करने का रास्ता अपनाया जा सकता है

    • package takeover policy कभी भी किसी दौर में वास्तव में तर्कसंगत नहीं थी
    • मेरा मानना है कि AUR helpers तो review step को workflow में शामिल करना और आसान बनाते हैं
      वे सक्रिय रूप से review करने को कहते हैं, और आख़िर में जोखिम स्वीकार करने के बाद यह भी बताते हैं कि कोई बदलाव हुआ है या नहीं
      हालाँकि, “AUR हानिकारक है” वाला नज़रिया नया नहीं है। AUR इस्तेमाल करने वालों को यहाँ के जोखिम समझने चाहिए, और यह मूलतः StackOverflow से मिली किसी चीज़ पर curl | bash चलाने से बस एक कदम बेहतर है

  • इस घटना को 7 घंटे से ज़्यादा हो चुके हैं, फिर भी archlinux.org या aur.archlinux.org पर अभी तक इसका कोई ज़िक्र नहीं है। समझ नहीं आता क्यों। जब तक ऐसा कोई कदम न उठाया जाए जिससे साबित हो कि यूज़र इस घटना से वाकिफ़ हैं, तब तक AUR को बंद कर देना चाहिए था
    उदाहरण के लिए, AUR API URL में थोड़ा बदलाव किया जा सकता था ताकि yay/yaourt यूज़र यह पता लगाने को मजबूर हों कि क्या हुआ है। नए API में यूज़र को सूचित करने और आगे बढ़ने से पहले यह पुष्टि कराने की व्यवस्था होनी चाहिए कि उन्होंने संदेश पढ़ लिया है। खासकर तब, जब यह भी पक्का नहीं है कि सारा malware ढूंढ लिया गया है
    इसके अलावा, एक revoked या compromised AUR commit database होना चाहिए, और ऐसा mechanism भी होना चाहिए जो यूज़र को चेतावनी दे अगर उन्होंने वह package इंस्टॉल किया हो

    • अच्छा हो या बुरा, AUR में यह चेतावनी हमेशा से मौजूद है
      इसके नाम में भी है, और wiki सामग्री में भी साफ़ लिखा है कि AUR एक user repository है और उस पर आँख मूंदकर भरोसा नहीं करना चाहिए
      ठीक ऊपर वाले बड़े लाल बॉक्स में यही लिखा है: https://wiki.archlinux.org/title/Arch_User_Repository
      AUR में बहुत सी ऐसी चीज़ें हैं जिन्हें आपको कभी इंस्टॉल नहीं करना चाहिए, और मुझे नहीं लगता कि उन सबको mailing list में भेजना सबसे अच्छा तरीका होगा
      malicious package इंस्टॉल करने वाले यूज़र्स को चेतावनी देने का विचार मुझे बुरा नहीं लगता, लेकिन इसे लागू कर पाना मुश्किल है। AUR में commercial tools जैसी install tracking नहीं है। कौन किस package को इंस्टॉल कर चुका है, यह कैसे पता चलेगा? AUR मूल रूप से package locations की directory जैसा है, और login या authentication जानकारी भी नहीं मांगता
      इसलिए चेतावनी उन tools से आनी चाहिए जिन्हें यूज़र ध्यान दें तो चला सकें, और जो वास्तव में ध्यान देने की मांग करें। उदाहरण: https://gist.github.com/Kidev/59bf9f5fb53ab5eee99f19a6a2fc39...
    • ऐसा नहीं होना चाहिए। सिर्फ इसलिए कि कुछ लोग बुनियादी security advice को गंभीरता से नहीं लेते, सबके workflow को नहीं तोड़ देना चाहिए
      नया API यूज़र को सूचित करे और यह पुष्टि करवाए कि उन्होंने पढ़ लिया है — यह आखिर काम कैसे करेगा? AUR package तो बस git repositories हैं, और AUR helpers क्या करते हैं या नहीं करते, इसे Arch maintainers नियंत्रित नहीं कर सकते
    • मुझे लगता है AUR के पहले पेज पर सूचना लगनी ही चाहिए। व्यक्तिगत रूप से, मुझे लगता है Arch homepage पर एक छोटा नोट और AUR page notice का लिंक भी मददगार होगा
      अगर वे सभी known affected packages की सूची नहीं देना चाहते, तो कम से कम आधिकारिक तौर पर यह सलाह तो देनी चाहिए कि AUR packages इस्तेमाल करने वाले लोग अपने इस्तेमाल किए जाने वाले हर package की हर file पढ़ें
    • अब सूचना आ गई है: https://archlinux.org/news/active-aur-malicious-packages-inc...
    • अगर Socket.dev के आँकड़ों पर भरोसा किया जाए, तो असर शुक्र है कि काफ़ी सीमित लगता है
      यह कुछ हद तक समझ में भी आता है। प्रभावित सूची में कुछ packages को मैं जानता हूँ, वे बहुत पुराने हैं और उनके upstream projects भी अब maintain नहीं किए जा रहे
      कुल पीड़ित कितने हैं, यह पता नहीं, लेकिन AUR टीम के पास सटीक संख्या होने की काफ़ी संभावना है। मेरा मानना है कि वे प्रभाव के स्तर के हिसाब से भरसक सही तरीके से निपट रहे होंगे

  • ऐसी घटना आखिरकार होना लगभग तय था, और अगर कुछ नहीं बदला तो आगे यह और ज़्यादा बार हो सकती है। मुझे AUR PKGBUILD system बहुत पसंद है, और मैं खुद लिखते समय भी इसका अक्सर उपयोग करता हूँ
    सबसे गंभीर और साथ ही सबसे आसानी से सुधारे जा सकने वाली समस्या यह है कि orphaned packages को कोई भी अपने हाथ में ले सकता है, लेकिन अंतिम यूज़र को इसकी कोई जानकारी नहीं दी जाती
    packages को delete करवाने में मेहनत ज़्यादा और फायदा कम है, इसलिए नियंत्रण छोड़ने का सबसे आसान तरीका उन्हें orphaned package बना देना बन जाता है। मेरे हिसाब से इसका उलटा होना चाहिए। कम से कम यूज़र को यह साफ़-साफ़ पता होना चाहिए कि कोई package orphaned हो गया है
    यह ज़िम्मेदारी paru या yay जैसे AUR helpers पर ज़्यादा हो सकती है, और मैं उन्हें ऐसे बदलाव करने के लिए प्रोत्साहित करूँगा

  • compromised packages को scan करने के लिए एक simple script है
    https://cscs.pastes.sh/aurvulntest20260611.sh
    यह मेरी script नहीं है, लेकिन पढ़ने और समझने में आसान है। किसी भी script को सीधे bash में pipe कभी नहीं करना चाहिए

    • एक तेज़ विकल्प भी है
      comm -1 -2 <(pacman -Qq | sort) <(curl -s https://gist.githubusercontent.com/quantenProjects/… | sort)
      comm(1) सीखने के लिए कभी बुरा समय नहीं होता
    • यह सिर्फ यह जाँचता है कि package इंस्टॉल हुआ था या नहीं, यह नहीं कि इंस्टॉल किया गया version संक्रमित था या नहीं
      शायद अगर मेरी तरह आपने कुछ समय से, यानी कई महीनों से, yay -Syu नहीं चलाया है तो आप सुरक्षित होंगे? …होंगे न?
      धत्त, मुझे Arch फिर से इंस्टॉल करने पर मजबूर मत करो। पिछली बार एक हफ़्ता लग गया था
      अपडेट: archinstall बढ़िया है। लगभग 15 मिनट में फिर से restore कर लिया
    • इस बात की कोई गारंटी नहीं है कि वह सूची पूरी है
      PKGBUILD और source को हमेशा जाँचना चाहिए। AUR मूल रूप से भरोसा करने लायक नहीं है। बल्कि ज़्यादा हैरानी इस बात की है कि ऐसा compromise इससे पहले नहीं हुआ
    • pacman date locale को सपोर्ट करता है, इसलिए 9 Jun खोजने वाला तरीका सिर्फ English locale या उसी तरह के format वाले locale में ही काम करेगा
      अपने environment के हिसाब से ठीक करने के बाद jd-gui मिला, लेकिन मैंने वास्तव में compromise से लगभग दो घंटे पहले jd-gui-bin इंस्टॉल किया था। लगता है उस रात source compile होने का इंतज़ार न करके -bin package चुन लेने की मेरी आलस ने मुझे बचा लिया

  • Arch कम्युनिटी तेज़ी से scripts और tools जारी कर रही है
    अभी infection की जाँच के लिए सबसे नया integrated utility यह है:
    https://github.com/lenucksi/aur-malware-check
    साथ ही aur-request mailing list पर malicious commits को revert करने के लिए deletion और orphaning requests भी बड़ी संख्या में आ रही हैं:
    https://lists.archlinux.org/archives/list/aur-requests@lists...

    • यह शायद शुरुआती सवाल है, लेकिन यह Arch या किसी official source से नहीं आया, तो यह कैसे पता चले कि इस पर भरोसा किया जा सकता है?
      उस script में बहुत सी बातें समझना मुश्किल हैं, इसलिए सिर्फ code पढ़कर यह तय करना आसान नहीं कि वह सुरक्षित है या नहीं
      उम्मीद होती है कि official Arch developers की तरफ़ से कोई प्रतिक्रिया या समाधान आए
    • repository README के नीचे का star graph अच्छा लगा
      यह ऐसे बड़े malware attack की तात्कालिकता और गंभीरता को अच्छी तरह दिखाता है

  • मुझे याद है कि लगभग 10 साल पहले मैंने Arch Linux पर emulator Mednafen install किया था। प्रोग्राम चला ही नहीं, क्योंकि वह ऐसी library से link था जो मेरे system में थी ही नहीं
    बाद में पता चला कि maintainer ने software को अपने system पर build किया था, और वहाँ मौजूद library इस्तेमाल हो गई थी, लेकिन dependency में लिखी नहीं गई
    वह एक official maintained package था, और मैं हमेशा सोचता था कि ऐसी चीज़ें dedicated build servers पर बनती होंगी, न कि किसी random volunteer या home computer पर। Arch आज भी उसी तरह build करता है या नहीं, यह नहीं पता, लेकिन वह घटना इतनी डरावनी थी कि मैंने distro ही बदल लिया

    • pkgctl build इस्तेमाल करने पर भी यह हो सकता है। मामला यह होता है कि makedepends= transitive तरीके से build environment में shared library ले आता है, लेकिन depends= में वह छूट जाती है
      .so dependency detect होने पर warning तो मिलती है, लेकिन उसे देखकर कार्रवाई करना maintainer की ज़िम्मेदारी है
      safety और security के लिहाज़ से Arch Linux reproducible builds प्रोजेक्ट को आगे बढ़ाने वाले प्रमुख पक्षों में से एक है, और OS का बड़ा हिस्सा इस बात के लिए independently verify किया जा सकता है कि binary वास्तव में source code से build हुई है या नहीं। official packages के लिए इसका audit system NixOS से मज़बूत और Debian के लगभग बराबर है:
      https://reproducible.archlinux.org/
      लेकिन यह सब इस बार की AUR घटना से पूरी तरह अलग बात है
    • ऐसी चीज़ पकड़ने के लिए ऐसे tools हैं जिनसे आप clean image में package build और install करके देख सकते हैं। उदाहरण के लिए pkgctl
      maintainer को publish करने से पहले ऐसे tools ज़रूर इस्तेमाल करने चाहिए
    • काफ़ी हाल तक यही तरीका आम था। Debian भी लंबे समय तक ऐसे ही चलता रहा, और 2019 में जाकर इसे पूरी तरह प्रतिबंधित किया गया

  • इसका समाधान क्या है? क्या ऐसे packages को network access के बिना Docker container के अंदर install करना चाहिए? मुझे नहीं लगता कि यह मान लेना चाहिए कि यह सिर्फ AUR तक सीमित है
    2026 में software के हर source पर शक करना चाहिए। खासकर जब vibe coding फैल चुकी हो, और closed-source software तो black box होता है, इसलिए open source से भी बड़ा mess है

    • भरोसेमंद न होने वाले “app stores”, जिनमें AUR, Flatpak वगैरह शामिल हैं, उन्हें sandbox के अंदर होना चाहिए। कम से कम default या option के तौर पर virtual machine जैसी isolation तो चाहिए ही
    • यह कहना अच्छा नहीं लग रहा, लेकिन Qubes OS वाले सही थे। समाधान है apps को virtual machines में आक्रामक तरीके से isolate करना
      अगर कोई सच में switch करे, तो क्या किसी को पता है कि battery life कितनी खराब हो जाती है?
    • SLSA अपनाने की ज़रूरत है
    • Flatpak

  • इस पर और ख़बरें आ रही हैं
    https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised
    मैंने कभी यह idea सोचा था कि एक canary binary बनाई जाए जो run होते ही बस email भेज दे या notification दिखा दे, और उसका नाम npm रख दिया जाए
    इस समय npm binary का नाम न बदलना अपने आप में बड़ा risk है