KeePassXC Debian मेंटेनर ने सभी नेटवर्क फ़ीचर हटाए

 (fosstodon.org/@keepassxc)
1 पॉइंट द्वारा GN⁺ 2024-05-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • अगर Debian का keepassxc पैकेज न्यूनतम फ़ीचर पैकेज में बदलता है, तो मौजूदा फ़ीचर बनाए रखना चाहने वाले उपयोगकर्ताओं को keepassxc-full पर स्विच करना होगा
  • हटाए जाने की सीमा सिर्फ networking तक नहीं है, बल्कि इसमें YubiKey, auto-type, browser integration, SSH agent, FDO secrets, favicon डाउनलोड और HIBP भी शामिल हैं
  • Debian पैकेज विवरण बताता है कि बेस keepassxc केवल “bare minimal functionality” देगा, और networking, SSH agent, browser plugin, FDO secret storage को सुरक्षा संबंधी जटिलता के रूप में वर्गीकृत करता है
  • बदलाव की सूचना NEWS.Debian.gz और apt-listchanges के जरिए दी जाएगी, और stable उपयोगकर्ताओं को release notes देखनी चाहिए
  • पैकेज नाम और migration तरीका अभी भी बदल सकता है, और Trixie के बाद apt install keepassxc पर दो विकल्प दिखाने का विचार सामने आया है

Debian keepassxc पैकेज में बदलाव

  • Team KeePassXC ने Debian उपयोगकर्ताओं को बताया कि keepassxc पैकेज का मेंटेनर बड़े पैमाने पर फ़ीचर हटाने की योजना बना रहा है
  • अगर यह बदलाव testing/sid से बाहर लागू होता है, तो जिन उपयोगकर्ताओं को मौजूदा फ़ीचर चाहिए, उन्हें keepassxc-full पर स्विच करना होगा
  • Debian bug report से यह networking disable करने जैसा दिखता है, लेकिन Team KeePassXC का कहना है कि असली बदलाव networking से आगे जाकर लगभग पूरे फ़ीचर हटाने जैसा है

हटाए जाने वाले फ़ीचरों का दायरा

  • Team KeePassXC के अनुसार हटाए जाने वाले फ़ीचर ये हैं
    • YubiKey
    • auto-type
    • browser integration
    • SSH agent
    • FDO secrets
    • networking
    • favicon डाउनलोड
    • HIBP

Debian पैकेज विवरण और उसका आधार

  • Debian sid में keepassxc पैकेज का विवरण बताता है कि बेस पैकेज में केवल न्यूनतम फ़ंक्शन होंगे
  • उस विवरण में networking, SSH agent, browser plugin, FDO secret storage को सुरक्षा संबंधी जटिलता माना गया है, और जरूरत होने पर keepassxc-full इस्तेमाल करने की सलाह दी गई है
  • संबंधित Debian bug report के रूप में #953529 - keepassxc: Compiling with disable networking support साझा की गई है

Debian मेंटेनर का रुख

  • Debian मेंटेनर ने कहा कि अनपेक्षित बदलाव देखने की पहली जगह /usr/share/doc/<package>/NEWS.Debian.gz है
  • testing/unstable उपयोगकर्ता, अगर apt-listchanges इंस्टॉल है, तो बदलाव अपने-आप देख सकते हैं, और stable उपयोगकर्ताओं को release notes पढ़नी चाहिए
  • उनके अनुसार इस फैसले पर 1 साल से चर्चा चल रही थी, और xz-utils घटना के बाद डिफॉल्ट रूप से शामिल कोड को जितना हो सके कम रखने की दिशा मजबूत हुई
  • मेंटेनर का कहना है कि Debian, KeePassXC, और ज़्यादा फ़ीचर वाले password manager चाहने वाले उपयोगकर्ताओं का overlap बहुत बड़ा नहीं है
  • उन्होंने कहा कि केवल local password manager में “छेद” डालना समझदारी नहीं है

upstream और downstream के बीच संचार समस्या

  • एक उपयोगकर्ता ने सवाल उठाया कि चर्चा लंबे समय से चल रही थी, फिर भी upstream डेवलपर पूरी तरह चौंके हुए क्यों दिखे
  • Debian मेंटेनर ने जवाब दिया कि यह Debian प्रोजेक्ट के अंदर का मामला है, और उन्होंने IRC पर दूसरे Debian डेवलपरों से राय ली थी
  • उन्होंने कहा कि upstream की राय उन्हें पहले से पता थी, upstream कुछ साल पहले IRC छोड़ चुका है, और नए version की packaging में ही काफी ऊर्जा लग जाती है
  • Team KeePassXC और कुछ उपयोगकर्ताओं ने चिंता जताई कि downstream के फैसले से upstream पर bug reports और confusion का बोझ बढ़ सकता है

पैकेज नाम और migration की दिशा

  • कई उपयोगकर्ताओं ने सुझाव दिया कि बेस keepassxc को न्यूनतम फ़ीचर पैकेज बनाने के बजाय keepassxc-minimal या keepassxc-light जैसा नाम देना कम भ्रमित करने वाला होगा, और मौजूदा keepassxc को full-featured ही रहना चाहिए
  • एक प्रस्तावित संरचना यह थी
    • keepassxc-light
    • keepassxc-full
    • keepassxc को transition package बनाया जाए जो keepassxc-full पर निर्भर हो
    • NEWS.Debian में बदलाव की व्याख्या दी जाए
  • Debian मेंटेनर ने कहा कि नाम बदलना ftpteam की मंजूरी पर निर्भर करता है, और Trixie के लिए transition package वाला तरीका शायद सबसे अच्छा प्रस्ताव हो सकता है
  • Trixie के बाद transition package हटाने और apt install keepassxc पर दो विकल्प दिखाने की संभावना पर भी चर्चा हुई

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

1 टिप्पणियां

 
GN⁺ 2024-05-12
Hacker News राय

  • upstream ने software में जो features रखे थे, उन्हें बड़े पैमाने पर हटाकर उसी नाम से distribute करना, अच्छे से अच्छा देखें तो भी संदिग्ध लगता है
    अगर वे इसी दिशा में जाना चाहते हैं, तो इसे किसी अलग नाम वाले fork के रूप में distribute करना चाहिए, ताकि upstream को users की समस्याओं की शिकायतों से लगातार परेशान न होना पड़े
    पहले Debian के Chromium maintainer ने extension install करने वाला feature एकतरफा disable कर दिया था, और अंत में वह patch revert करना पड़ा था—वह बात याद आती है
    उससे भी बहुत पहले Debian ने network card में binary firmware load करने वाला kernel interface हटा दिया था, जिससे मेरा network टूट गया था—वह भी याद आता है

    • असल में जो किया गया वह सिर्फ XC_ALL build parameter को OFF में बदलना था [0], और यही value upstream CMakeLists.txt की default value भी है 1
      अगर upstream इस feature को इतना महत्वपूर्ण मानता है, तो उसे पहले default value ठीक करनी चाहिए
      upgrade के बाद feature बंद हो जाने से users भ्रमित हो सकते हैं, लेकिन बिना suffix वाला package upstream default से मेल खाता है, यह अपने-आप में काफी तर्कसंगत है

      [0] https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
      1 https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...

    • maintainer की भूमिका upstream को copy-paste करने से अधिक होती है
      distribution के end users के लिए क्या उपयुक्त है, इसका निर्णय लेने का अधिकार उसे होता है
      इस मामले में एक तर्कसंगत security rationale दिखता है, और वैकल्पिक package भी उपलब्ध है

    • Debian शायद अकेला distribution है जिसका upstream को नज़रअंदाज़ करने वाला अजीब रवैया है
      मेरे द्वारा maintain किए जाने वाले दो upstream projects में भी Debian ने एकतरफा package का नाम बदल दिया
      एक के बारे में मुझे काफी बाद में पता चला, और दूसरे में मैंने साफ विरोध किया था, फिर भी यह पूरी तरह बेतुके तरीके से आगे बढ़ा
      अंत में users को समझाना मुझे ही पड़ता है

      सुधार: यहां Debian पक्ष के Julian का अहंकार देखा जा सकता है: https://github.com/keepassxreboot/keepassxc/issues/10725#iss... — मैं इसी तरह की बात कह रहा हूं

    • upstream ने जो बनाया था, उसे “काट-छांटकर निकाला” नहीं गया है
      plugin के बिना version distribute किया गया है, और plugin शामिल वाला -full version बनाया गया है
      अगर plugin default रूप से लगा हुआ है, तो वह plugin नहीं, built-in feature है, और यह तरीका सही है

    • अगर Apple कहता कि “हमें लगा कि security के लिहाज से बेहतर है, इसलिए हमने आपका app modify कर दिया,” तो लोग मशालें और pitchforks लेकर निकल पड़ते
      लेकिन जब deb maintainer ऐसा करता है, तो यह बहस का मुद्दा बन जाता है
      अगर security issue है, तो unsafe version उपलब्ध ही नहीं कराया जाना चाहिए, लेकिन इस मामले में ऐसा भी नहीं है
      App Store जैसी दुनिया में maintainer की भूमिका बदलनी चाहिए
      काम software को distribution पर चलने लायक बनाना है, न कि नाम बनाए रखते हुए अपनी पसंद के हिसाब से pseudo-fork बनाना

  • यह काफी तर्कसंगत फैसला लगता है
    network features और browser integration बड़े संभावित छेद और attack entry points हैं
    अगर network-related features के बिना केवल trusted database चलाया जाए, तो vulnerability मिलने पर भी tool का दुरुपयोग करना लगभग असंभव होना चाहिए, और password manager जैसे महत्वपूर्ण tool के लिए यह बेहद वांछनीय गुण है
    original maintainer भी सहमत है 1
    network enabled वाला full package भी Debian में है, इसलिए जो users चाहें, वे बस apt install keepassxc-full करके सभी network features इस्तेमाल कर सकते हैं
    हालांकि upstream को “crappy”[0] कहना package maintainer के रूप में productive रवैया नहीं है, और package names भी keepassxc और keepassxc-full के बजाय keepassxc-lite और keepassxc-full होते तो Debian users के लिए ज्यादा समझने योग्य होते

    [0] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

    1 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

    • बहुत-सी चीजें बड़े संभावित छेद और attack entry points होती हैं, और साथ ही उपयोगी भी होती हैं
      “उपयोगिता” security बढ़ा सकती है
      क्योंकि अगर password manager इस्तेमाल करना मुश्किल हो, तो लोग उसे इस्तेमाल करना छोड़ देते हैं
      थोड़ा और देखने पर यह भी स्पष्ट नहीं है कि clipboard का उपयोग browser integration से अनिवार्य रूप से अधिक सुरक्षित है
      सिर्फ copy/paste की गलतियां ही browser integration के security burden के बड़े हिस्से की भरपाई कर सकती हैं
      बहुत पहले मैंने एक बड़ी company में contract work किया था; account managers के laptops पर disk encryption password, Windows login password और AD login password होते थे, सभी अलग होने जरूरी थे, हर कुछ महीनों में बदलने पड़ते थे, और complexity requirements भी कड़ी थीं
      मैंने जितने भी laptops देखे, उनमें बिना किसी exception के तीनों passwords लिखी हुई post-it चिपकी हुई थी
      मुद्दा यह है कि काल्पनिक security-nerd वाली security वास्तविक दुनिया की security जैसी नहीं होती
      कम-से-कम हमेशा तो नहीं, और यहां वास्तविक trade-offs की जरूरत होती है

1: हमने बाहरी contractor के तौर पर कुछ कर्मचारियों के laptops का maintenance किया था
असल में ऐसा नहीं होना चाहिए था, लेकिन company IT system के ज़रिए करने पर bureaucracy के कारण बहुत ज़्यादा समय लगता था, इसलिए यह कहीं तेज़ और आसान था
कंपनी उसी तरह की थी
यह अपने आप में भी साफ़ तौर पर “security risk” था, क्योंकि किसी computer shop का कोई random technician top-secret company data वाले laptop को छुए, यह वैसे भी सही नहीं है
हालांकि मुझे लगता है कि protect करने लायक चीज़ें इतनी ज़्यादा नहीं थीं। बस sales/customer numbers जैसी चीज़ें थीं, और वे भी बहुत सीमित लोगों के लिए ही उपयोगी जानकारी थीं

  • Browser integration में manual copy/paste की तुलना में security बढ़ाने वाला एक पहलू है
    Browser extension credentials भरने से पहले page URL verify करता है, जबकि manual copy/paste typo domains या homoglyph phishing के लिए vulnerable है

  • मैं सहमत हूँ कि network features और browser integration बड़े potential holes हैं, लेकिन GitHub issue के participants ने जैसा कहा, यह महत्वपूर्ण है कि full build की तुलना में reduced build tests लगभग नहीं हैं, और arbitrary build flag combinations तो बिल्कुल test नहीं किए जाते
    जैसा दूसरी जगह भी सामने आया, disabled “optional” flags में से एक yubikey support है, और इसकी वजह से नए टूटे हुए package पर upgrade करने वाले users अपने password manager से lock out हो रहे हैं
    सिर्फ वही एक flag फिर से enable कर दें, तब भी स्थिति ऐसी हो जाती है जिसे असल में कोई test नहीं करता
    अगर यह मान लिया जाए कि existing users को keepassxc-full पर move किया गया, तो मैं सहमत हूँ कि keepassxc-lite नाम से problem रुक सकती थी
    लेकिन असली मुद्दा भी यही है
    सबसे सुरक्षित solution को default बनाना reasonable है, लेकिन maintainer को upstream या users की इच्छा के बिना existing functionality नहीं तोड़नी चाहिए, खासकर users को password manager से lock out नहीं करना चाहिए

  • GitHub पर “crappy” लिखना बहुत rude था; अगर मैं Debian इस्तेमाल कर रहा होता तो शायद use करने पर फिर से सोचता
    अगर package ऐसे घटिया features से भरा है, तो समझ नहीं आता कि उसे maintain करने की ज़हमत क्यों उठाई जाए
    बेहतर होगा कि उसे हटा दिया जाए और users खुद सही तरीके से install करने का तरीका ढूँढ लें
    KeepassXC developers के लिए बुरा लगता है; open source project maintain करना वैसे ही मुश्किल है, ऊपर से उन्हें ऐसी चीज़ें भी झेलनी पड़ती हैं

  • crappy शब्द देखते ही julian-klode के प्रति सम्मान तुरंत खत्म हो गया

  • drawks ने जो solution सुझाया, वह साफ़ तौर पर सही choice लगता है:

    उचित solution शायद software के "-full" और "-minimal" दोनों versions को package करना, Debian package metadata field के ज़रिए दोनों packages के बीच Conflicts relationship define करना, दोनों को keepassxc Provide करने के लिए tag करना, और -full build में Replaces: keepassxc tag भी जोड़ना होगा। तब package upgrade के दौरान existing users को upgraded/replaced package की functionality जारी रखने वाला version मिलेगा, और नए users खुद चुन सकेंगे कि कौन सा version install करना है

    https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

    समझ नहीं आता कि यह obvious choice क्यों नहीं हो सकती

    • क्योंकि maintainer का अपना view था, और वह explicitly default बदलना चाहता था

    • यह सिर्फ obvious choice ही नहीं था, बल्कि actual Debian में ठीक ऐसा ही हुआ: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...

      original post बस खराब तरीके से लिखा clickbait है
      कुछ भी remove नहीं किया गया; उसे बस keepassxc-full package में move किया गया है

  • उधर Arch में, शायद user base में काफ़ी common रूप से installed fwupd package को चुपचाप passim पर depend करने के लिए set कर दिया गया, और passim explicit user consent के बिना 0.0.0.0:275001 पर open web server चला देता है
    ऊपर से passim GnuTLS इस्तेमाल करता है, जो holes के मामले में Swiss cheese से भी ज़्यादा बदनाम है 2
    मुझे यह सचमुच absurd लगता है, और chain में कहीं xz-type exploit छिपा हो तो भी हैरानी नहीं होगी

    • fwupd ढूँढने की भी ज़रूरत नहीं है
      हर जगह मौजूद systemd-resolved request आने पर port 5355 पर LLMNR server, यानी जिसे mDNS भी कहा जाता है और जो पुराने Microsoft NetBIOS परिवार से है, खोल सकता है
      Internet of Things की वजह से अब जब हर कोई मेरे LAN तक पहुँच सकता है, Linux को भी उस mess में शामिल कराया जा रहा है

      fwupd fix: default config file की quality खराब है और commented-out defaults भी नहीं हैं, तो ऐसे करें:

      # /etc/fwupd/fwupd.conf  
[fwupd]  
P2pPolicy=none

      resolved fix में /etc/systemd/resolved.conf में LLMNR=no commented out है, और शायद आप DNSStubListener=no भी चाहेंगे
      अच्छे defaults ऐसे हैं:

      # /etc/systemd/resolved.conf  
[Resolve]  
DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net  
FallbackDNS=127.0.0.1 ::1  
Domains=~.  
DNSOverTLS=yes  
LLMNR=no  
DNSStubListener=no

    • जानना अच्छा है
      लगता है यह अलग post के रूप में भी डाला जा सकता है

  • पैकेज maintainer को principle of least astonishment के हिसाब से चलना चाहिए, और जब तक कोई documented या कम-से-कम plausible जोखिम न हो, core features को disable नहीं करना चाहिए
    इस comment section में “plugin” शब्द अभी 25 बार आया है, लेकिन यहां बात plugin की नहीं है
    KeePassXC में कई features हैं, लेकिन ऐसा कुछ नहीं दिखता जो explicit user action के बिना अपने-आप vulnerability का संभावित बड़ा स्रोत बन जाए
    Browser integration को configure करने से पहले पहले enable करना पड़ता है, और इस flag से disabled हुए दूसरे features भी शायद ऐसे ही हैं, इसलिए -minimal package ज्यादा उचित होता
    अनिश्चित भविष्य में इस बदलाव से फायदा पाने वाले बेहद थोड़े users की तुलना में, browser integration इस्तेमाल करने वालों को होने वाली गंभीर असुविधा कहीं ज्यादा बड़ी है
    Browser integration आम तौर पर clipboard access से कहीं ज्यादा सुरक्षित feature भी है
    यह project के vision से भी मेल खाता नहीं दिखता:

    लक्ष्य ऐसा application बनाना है जिसे कोई भी इस्तेमाल कर सके, और जिन्हें जरूरत हो उन्हें advanced features भी मिलें

  • मौजूदा users को तोड़े बिना भी यह separation किया जा सकता था, इसलिए इसे Debian package maintainer का खराब फैसला मानने के अलावा और तरह से देखना मुश्किल है
    Network features के बिना KeepassXC इस्तेमाल कर पाना निश्चित रूप से अच्छा है, लेकिन browser integration को niche feature मानना वास्तविकता से बहुत दूर है
    मैं दांव लगा सकता हूं कि Debian पर अभी KeepassXC इस्तेमाल करने वाले आधे से ज्यादा, शायद उससे भी कहीं ज्यादा users, उन features को चाहते हैं जिन्हें इस तरीके से बिना warning disable कर दिया जाएगा
    आखिरकार फैसला लेने का अधिकार उन्हीं के पास है, लेकिन इसका मतलब यह नहीं कि फैसला अच्छा है; मेरे हिसाब से नहीं है

  • KeePassXC maintainer ने कहा:

    इस thread के शुरू होने से पहले हमें तीन reports मिली थीं कि इस नए packaging तरीके ने लोगों के workflows बिगाड़ दिए। एक case में yubikey functionality हट जाने से user अब अपना database खोल ही नहीं पा रहा था। जरा सोचिए। जो व्यक्ति अपने सबसे महत्वपूर्ण secrets तक access खो देता है, वह panic में कभी-कभी irrational हरकतें कर सकता है

    https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

    • अगर आप offline password manager इस्तेमाल करते हैं और backup नहीं है, तो मानकर चलिए कि सब कुछ खो गया
      यह emotional blackmail जैसा सुनाई देता है
      पता नहीं कितनी बार hardware failure, OS को तोड़ देने वाले update, गलत drive पर dd इस्तेमाल करने आदि से लोगों ने सब कुछ खोया है

  • अगर downstream maintainer upstream project की मंशा से अलग तरीके से package बदलना चाहता है, तो मेरी राय में उसे इसे अलग नाम से distribute करना चाहिए और उस modified version से पैदा होने वाली सभी bug reports खुद handle करनी चाहिए

    • Default build में networking OFF है
      Yubikey, browser integration आदि के लिए भी यही बात है

      -DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF)

      https://github.com/keepassxreboot/keepassxc/blob/develop/INS...

    • WITH_XC_NETWORKING build option default रूप से off है, इसलिए साफ है कि developers ने इस configuration को valid build setting के रूप में intend किया था

    • मुझे पता है कि आम तौर पर इसका ठीक से पालन नहीं होता, लेकिन मूल default flow यही है
      अगर distro-provided package इस्तेमाल करते हुए bug मिले, तो distro package पर bug खोलना चाहिए; maintainer उसे देखकर अगर bug upstream से आया हो तो upstream project में भेजे
      यह तरीका इसलिए उपयोगी है कि 1. package maintainer उस package से परिचित होता है, इसलिए initial triage और analysis कर सकता है, और upstream तक जाने से पहले ही fix भी कर सकता है, और 2. जैसा कहा गया, distro packages में अक्सर patches होते हैं, इसलिए maintainer को जांचना चाहिए कि समस्या packaging में है या upstream source में
      दुर्भाग्य से कई users पहले upstream में report करते हैं
      इसलिए practical तौर पर चिंता की बात है, लेकिन ideally ऐसा नहीं होना चाहिए

    • नहीं तो end user को दिखाना चाहिए कि यह unsupported package है
      जैसे इसे KeePassXC-Debian या KeePassXC-Unsupported के रूप में दिखाया जाए, और About में developer contact या website हटाकर Debian support information रखी जाए
      Operating system के हिसाब से downstream के छोटे बदलाव ठीक हैं
      लेकिन app को modify करके core features हटाना और upstream developers पर भारी complaints का बोझ डालना ठीक नहीं है

    • समझ नहीं आता कि linked 200-character post भी पढ़े बिना लोग comment क्यों कर रहे हैं
      Maintainer ने keepassxc-full package में network-related समेत सभी plugins enable किए हैं, और keepassxc package में सिर्फ basic functionality रखी है जिसकी security posture कहीं बेहतर है
      यह स्पष्ट रूप से पूरी तरह ठीक है और maintainer के अधिकार क्षेत्र में है
      पूरी complaint बस इस बात पर है कि यह एक change है

  • जिनकी दिलचस्पी है, उनके लिए GitHub का यह issue latest comments रखता दिखता है

    https://github.com/keepassxreboot/keepassxc/issues/10725

    • Debian maintainer Julian Klode का नजरिया काफी तेज-तर्रार है:

      अफसोस, ऐसा नहीं होगा। default रूप से सभी plugins build करके distribute करना एक गलती थी। Users जिस NEWS file को पढ़ना चाहिए, उसे वे परेशान करने वाली हद तक नहीं पढ़ते, इसलिए करीब 1 साल तक दर्द रहेगा, लेकिन इसमें बहुत कुछ किया नहीं जा सकता।

      Users को default के रूप में सबसे सुरक्षित विकल्प देना हमारी जिम्मेदारी है। ये सभी features unnecessary हैं और local password database manager में वास्तव में belong नहीं करते। Development की यह पूरी दिशा पूरी तरह गलत है।

      जिन users को यह कचरा चाहिए वे कचरा version install कर सकते हैं, लेकिन जाहिर है इससे drive-by contributor attack का जोखिम बढ़ता है।

  • Title गलत है
    Original post में कहा गया था कि maintainer ने सिर्फ network features ही नहीं बल्कि सभी features हटा दिए, और यह सच था क्योंकि सचमुच सभी optional features, यहां तक कि पूरी तरह offline features भी build के दौरान off कर दिए गए थे