"हमारे paid customers को X चाहिए, आप इसे कब ठीक करेंगे?"

 (twitter.com/maximilianhils)
2 पॉइंट द्वारा GN⁺ 2023-07-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • regulated industries (बैंक, federal agencies आदि) में customers रखने वाले एक enterprise user ने open-source tool mitmproxy के अगले release schedule की मांग एक public issue में की, और यह दबाव डाला कि known High और Critical vulnerabilities के कारण उनके customers यह software इस्तेमाल नहीं कर सकते
  • यह vulnerability उस library के हिस्से में मौजूद है जिसे mitmproxy इस्तेमाल नहीं करता, इसलिए वास्तविक users पर इसका असर नहीं है
  • maintainer ने अनुरोध को ठुकराया नहीं; बल्कि जवाब दिया कि अगर समय पर patch release चाहिए, तो paid support contract किया जा सकता है, और profile में दिए email की ओर इशारा किया
  • enterprise user ने इस जवाब को "या तो मज़ाक या चतुराई से छिपाई गई जबरन वसूली की कोशिश" माना और विरोध में email भेजा
  • release schedule पूछना अपने-आप में जायज़ है, लेकिन मुख्य बात यह है कि "contribution या funding से हम कैसे मदद कर सकते हैं" जैसी सहयोगी सोच चाहिए; मूल comment लिखने वाले ने बाद में दिल से माफ़ी भेजी

घटना की पृष्ठभूमि

  • जुड़े हुए context explanation के अनुसार, mitmproxy के साथ distribute होने वाली एक library में vulnerability मौजूद है, लेकिन वह उस हिस्से में है जिसे mitmproxy इस्तेमाल नहीं करता, इसलिए वास्तविक users पर असर नहीं है
  • यह मामला बाहर चर्चित (went viral) होने के बाद अतिरिक्त संदर्भ समझाया गया

enterprise user की शुरुआती मांग (GitHub issue)

  • 16 घंटे पहले एक user ने project के दूसरे member @Prinzhorn को mention करते हुए अगले release की target date पूछी
  • उसने बताया कि बैंक और federal agencies जैसे regulated industries के customers को नियमों के तहत known High और Critical severity vulnerabilities वाले software का इस्तेमाल करने की अनुमति नहीं होती
    • वे इंतज़ार (waiting) को लेकर अपनी company की position तय करना चाहते हैं, लेकिन इसके लिए किसी न किसी तरह की target date चाहिए

maintainer mhils का जवाब

  • member mhils ने 15 घंटे पहले जवाब देते हुए कहा कि अगर company के compliance requirements पूरे करने के लिए समय पर patch releases में रुचि है, तो वे support contract set up करने को तैयार हैं
  • contact details profile में दिए email में हैं, ऐसा बताया (":-)" notation सहित)

विरोध email ("Concerning response")

  • इसके बाद us.ibm.com domain वाले address से github@hi.ls पर "Concerning response" subject के साथ email भेजा गया (Jul 14, 2023 के रूप में अंकित)
  • "Mr. Hils" से शुरू करते हुए, email में कहा गया कि मामले को escalate करने या GitHub issue tracker को अनावश्यक बातों से भरने के बजाय, वे सीधा जवाब पाने के लिए target date request को बेहतर ढंग से समझाना चाहते हैं
    • उम्मीद जताई कि इस follow-up mail को अपमानजनक न माना जाए, और स्पष्ट किया कि यह उनका इरादा नहीं है
  • highlighted हिस्से में लिखा गया कि वे maintainer के जवाब को official project response नहीं, बल्कि मज़ाक, या उससे भी बुरा, चतुराई से छिपाई गई जबरन वसूली की कोशिश (thinly veiled extortion attempt) मान रहे हैं (इसके बाद project की official documentation देखते समय वाक्य बीच में कट जाता है)

maintainer का रुख

  • उन्होंने स्पष्ट किया कि जवाब मज़ाक नहीं था
  • "हमारे paid customers को X चाहिए, आप इसे कब ठीक करेंगे" जैसा approach open-source project में अपना परिचय देने का सबसे अच्छा तरीका नहीं हो सकता
  • उन्होंने माना कि release schedule पूछना अपने-आप में परेशान करने वाला नहीं है और यह जायज़ सवाल (valid) है
    • लेकिन मुख्य बात यह है कि इसका context "हम इस काम में रुचि रखते हैं, इसे संभव बनाने में कैसे मदद कर सकते हैं" (contribution या funding) होना चाहिए, न कि "आप हमारे customers के लिए समस्या पैदा कर रहे हैं"

समापन

  • मूल comment लिखने वाले ने दिल से माफ़ी (genuine apology) भेजी, और maintainer ने इसके लिए सच में आभार जताया
  • सभी से अच्छी नीयत मानकर चलने (assume good intentions) और दयालु रहने की अपील की

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

1 टिप्पणियां

 
GN⁺ 2023-07-16
Hacker News की राय

  • इस issue को पढ़ने परhttps://github.com/mitmproxy/mitmproxy/issues/6051 IBM का अनुरोध ट्वीट में दिखने वाली बात से कहीं ज़्यादा तर्कसंगत लगता है
    समस्या यह है कि mitmproxy की dependency में CVE है, और mitmproxy ने मार्च में dependency अपडेट कर दी थी, लेकिन उस अपडेट को शामिल करने वाली stable release अभी तक जारी नहीं की है। IBM की तरफ़ से सवाल यह है कि “release tag कब लगाने की योजना है, क्या कोई timeline है जो ग्राहकों को दी जा सके?”
    खास तौर पर यह नहीं पूछा जा रहा कि “इसे कब ठीक करोगे?”। ठीक करने लायक कुछ बचा नहीं है; सवाल असल में यह है कि “इस dependency update वाली नई release कब बनाने की योजना है?”
    मुझे यह सवाल अपने आप में अनुचित नहीं लगता। बेशक, अगर वे चाहते हैं कि ऐसा fix किसी तय समय सीमा में ship हो, तो support contract माँगना भी अनुचित नहीं है, लेकिन “support contract के लिए email करें” जैसा सीधा जवाब थोड़ा ज़्यादा सख्त लगता है

    • पहला सवाल विनम्र और तर्कसंगत था, और @mhils का जवाब भी वैसा ही था। जो बिल्कुल तर्कसंगत नहीं था, वह IBM की बाद की follow-up email में इसे “हल्का-सा ढका हुआ उगाही का प्रयास” कहना था
      Maximilian पर यह कोई ज़िम्मेदारी नहीं है कि वह बिना पैसे देने वालों को release schedule दे, और अगर IBM को सच में timeline चाहिए, तो उसके बदले पैसे देने को कहना भी बिल्कुल अजीब नहीं है। अगर IBM इसे इतना महत्वपूर्ण मानता है, तो वह आज ही mitmproxy की internal release खुद भी बना सकता है
    • Release date पूछना पूरी तरह से तर्कसंगत अनुरोध है। लेकिन मेरा जवाब संदर्भ से बहुत प्रभावित था
      मैंने “support contract के लिए email करें” इसलिए कहा क्योंकि 1) उसी thread में मैं पहले ही कह चुका था कि इस मामले के लिए patch release नहीं निकलेगी, और 2) सामने वाले ने इस बात पर ज़ोर दिया था कि इसका असर उनके paid customers पर पड़ रहा है
      इसलिए वहाँ मेरे पास कहने के लिए बस वही बचा था। मैं मानता हूँ कि इसे बेहतर तरीके से कहा जा सकता था, लेकिन मुझे नहीं लगता कि मेरा जवाब पूरी तरह हद से बाहर था
      CVE खुद भी बेकार है, और हम dependency के उस हिस्से का इस्तेमाल ही नहीं करते
    • वह हिस्सा काफ़ी स्पष्ट है। समस्या बाद की communication में इसे “हल्का-सा ढका हुआ उगाही” कहना है, और वह तर्कसंगतता से बहुत दूर की बात है
    • जैसा कि maintainer ने समझाया, वह CVE वास्तव में mitmproxy को प्रभावित नहीं करता। आखिरकार यह सिर्फ़ security team की एक checkbox हटाने में मदद करने जैसा है
      जब अनुरोध करने वाला मुफ्त श्रम से फ़ायदा उठा रहा है, तो maintainer मुफ्त में काम क्यों करे
      अनुचित बात FrugalGuy का entitlement है। open source maintainers से मुफ्त में काम करवाने की कोशिश करके फिर उसे उगाही कहना काफ़ी खास किस्म की पाखंडिता है। किसी volunteer से, जो part-time में free open source project चला रहा हो, आप अपनी माँग मनवा नहीं सकते
    • फिर भी, maintainer को email भेजते समय इस्तेमाल किया गया धमकी भरा लहजा नहीं बदलता

  • OP हूँ। साफ़ कर दूँ कि release के बारे में सवाल अपने आप में बिल्कुल ठीक और वैध है
    लेकिन संदर्भ यह होना चाहिए: “हमें इसमें दिलचस्पी है, इसे संभव बनाने के लिए हम कैसे मदद कर सकते हैं?” चाहे contribution से हो या पैसे से। यह नहीं कि “आपकी वजह से हमारे ग्राहकों को समस्या हो रही है”
    मेरी इच्छा यह नहीं है कि अनुरोध करने वाला एक गलत बात कहकर बुरी तरह फँस जाए, बल्कि यह है कि बड़ी कंपनियाँ free open source software के साथ एक स्वस्थ रिश्ता बनाएँ

    • अगर यह मेरा project होता, तो शायद मैं support contract का प्रस्ताव नहीं देता। labour law और tax law की बातें मेरे लिए बहुत जटिल हैं
      ऐसा contract ऑफ़र करना अपने आप में काफ़ी दयालु बात है। FrugalGuy को “pull request भेजो” जैसा जवाब भी मिल सकता था, और पता नहीं वह उसे पसंद आता या नहीं
    • भावनाओं और लोगों को अलग रखकर देखें, तो software project के रूप में मैं यह जानना चाहता हूँ कि आखिर mitmproxy को अभी तुरंत नई version release करने से रोक क्या रहा है
    • यह पढ़कर मैं अपना GitHub comment हटाना चाहता था, लेकिन thread लॉक था, इसलिए हटा नहीं सका
    • मुझे समझ नहीं आता कि contribution या पैसे से release की समस्या कैसे हल होगी। अगर bug है, तो उसे ठीक करके patch भेजा जा सकता है
      लेकिन अगर समस्या यह है कि पहले से बना हुआ fix release नहीं हुआ, तो contribution या पैसे से उसे कैसे ठीक किया जा सकता है, यह मेरी समझ से बाहर है
    • फिर भी, वह उगाही की कोशिश थी

  • यह उन information security बेवकूफों का एक क्लासिक उदाहरण लगता है जिन्हें यह भी नहीं पता कि वे किस चीज़ को “ठीक” कर रहे हैं। अगर automated system बता दे कि CVE है, तो वे मान लेते हैं कि इसे हर हाल में “patch” करना ही होगा
    वे यह नहीं देखते कि CVE का दावा वास्तव में क्या है, या उनके अपने खास usage pattern में वास्तव में vulnerability है भी या नहीं। उन्हें पता नहीं, दिलचस्पी नहीं, और वे programmer भी नहीं हैं। उन्हें बस इतना पता है कि checkbox हटानी है
    h2database में भी ऐसा ही कुछ हुआ था। एक “security researcher” ने यह खोज निकाला कि अगर आप वह काम करें जिसे करने से मना किया गया था, तो बुरी चीज़ें हो सकती हैं, और फिर भी उसने CVE की मांग की और उसे मिल भी गई। ध्यान से देखें तो यह बकवास है, लेकिन ऐसे लोगों के लिए सिर्फ CVE का मौजूद होना ही मायने रखता है
    h2database developer ने कहा: https://github.com/h2database/h2database/issues/3686#issueco...
    “यह समझना मुश्किल है कि मुझे उन ‘बड़ी कंपनियों’ के लिए ज़रा भी सहानुभूति क्यों रखनी चाहिए जो volunteer द्वारा बनाए गए open source project का इस्तेमाल करती हैं। कंपनी के पैसे से किसी को hire करके यह काम करवा लो, या किसी मिलती-जुलती commercial library के लिए पैसे दो”

    • हो सकता है वे यह सब जानते और समझते हों, फिर भी परवाह न करते हों। शायद उनकी performance इस बात से आंकी जाती हो कि वे checkbox कितनी जल्दी हटाते हैं, और ज़रूरत से ज़्यादा approve करने की तुलना में ज़रूरत से ज़्यादा reject करना कम नुकसानदेह माना जाता हो
      भले ही किसी खास स्थिति में exception देने का अधिकार हो, उस फैसले को justify करने के लिए शायद उन्हें और ज़्यादा paperwork करना पड़ता हो। वही अतिरिक्त paperwork रफ़्तार धीमी कर देता है और performance metrics पर बुरा असर डालता है
    • वाह, वह CVE तो हास्यास्पद है
      “अगर password command line से दिया जाए, तो सिस्टम के दूसरे process उसे ps से देख सकते हैं”
      यह तो बिल्कुल obvious है। अगर यह “high severity” CVE है, तो मुझे भी security researcher कहा जा सकता है। मैं कम-से-कम पाँच-छह applications के बारे में सोच सकता हूँ जो यही काम होने देती हैं और साथ में सिर्फ यह warning लगा देती हैं कि “ऐसा मत करो”
    • पूरी तरह सहमत हूँ। मैं एक regulated industry में काम करता हूँ, और flow कुछ ऐसा है
      infosec team रिपोर्ट में दिखी vulnerability आगे बढ़ाती है, और manager घबरा जाता है
      developer को लगातार update करते रहना पड़ता है। सिर्फ runtime ही नहीं, dependencies तक। exception के लिए apply किया जा सकता है, लेकिन वह अपने आप में एक अलग सिरदर्द है
      फिर manager सोचता है कि development work धीमा क्यों हो गया
    • मैं एक ऐसे SaaS vendor में काम करता हूँ जिस industry में SaaS को अभी भी थोड़ा “अनोखा” माना जाता है। हमें बेहूदा security questionnaires मिलती हैं, जिनमें 90% जवाब not applicable होते हैं
      बाकी जवाबों को वास्तव में कोई review भी करता है या नहीं, इस पर भी मुझे शक है

  • मेरे एक project पर भी अचानक “इसे कब ठीक करोगे”, “मैं भी इससे प्रभावित हूँ और यह महत्वपूर्ण है” जैसे comments की बाढ़ आ गई थी। इस तरह का अचानक interest काफ़ी अजीब था
    लेकिन लगभग उसी समय मुझे एक apology email मिला, जिसमें बताया गया था कि किसी कंपनी के boss ने अपने कर्मचारियों से कहा था कि वे मुझे दबाव में लाने के लिए ऐसा दिखाएँ मानो वास्तव में जितने लोग प्रभावित थे उससे कहीं ज़्यादा लोग प्रभावित हों

    • सबसे अच्छा जवाब है: “मेरी दर $XYZ प्रति घंटा है, और मैं cash या cheque लेता हूँ”

  • लगता है किसी ने अपने workplace पर यह सीख लिया कि आक्रामक या धमकीभरा लहजा बहुत असरदार होता है, लेकिन वह यह नहीं समझ पाया कि यहाँ negotiation की स्थिति बिल्कुल अलग है

    • अगर यह 27 साल तक करो, तो IBM में Program Manager Secure Engineering and Incident Response तक promote हो जाते हो

  • “मुझे यह जानना है कि यह कब तक होगा ताकि मैं planning कर सकूँ” और “मुझे तुम्हारे काम से पैसे मिल रहे हैं, इसलिए तुम्हें यह करना चाहिए, जल्दी करो” के बीच एक बारीक फ़र्क है
    अगर मांग करने वाले ने background information हटाकर पूछा होता, तो उसका लहजा पहले वाले के ज़्यादा करीब और दूसरे वाले से कम मिलता

    • मैं इससे सहमत नहीं हूँ कि वही सही तरीका था। open source project में यह बताना कि कोई चीज़ क्यों उपयोगी है, इसमें बिल्कुल कोई समस्या नहीं है
      अगर वह वजह बहुत से दूसरे users के लिए भी महत्वपूर्ण लगती है, तो maintainer को यह तय करने में मदद मिल सकती है कि feature addition या bug fix को जल्दी करना है या नहीं। अगर कोई workaround है, तो उसे खोजने में भी मदद मिल सकती है
      developer से वसूली करना कहना अनुचित था, लेकिन मुझे नहीं लगता कि पहले message में अपने आप में कोई समस्या थी

  • open source का इस्तेमाल करते हुए support तक माँगने वाली कंपनियों की entitlement बहुत ज़्यादा है। काश usage restrictions वाले licenses ज़्यादा व्यापक रूप से इस्तेमाल होते, और OSI सिर्फ “वह open source नहीं है!!!” कहकर न रह जाता।
    ऐसे licenses इस तरह की स्थिति को रोकने में मदद कर सकते हैं

    • GNU AGPLv3 corporate lawyers को इतना नाराज़ कर सकता है कि यह व्यवहार में लगभग non-commercial license की तरह काम करे। लेकिन वास्तव में यह non-commercial license नहीं है, और OSI व FSF दोनों के मानकों को पूरा करता है।
      फिर भी, यहाँ OSI और FSF का सख्त रुख लेना अच्छी बात है। अगर आपकी प्राथमिकताएँ उनसे मेल नहीं खातीं, तो वे आपको संतुष्ट करने के लिए क्यों बदलें?
      बस अपनी पसंद का license इस्तेमाल करें। चाहे वे उसे approve न करें। यह समस्या क्यों है, समझ नहीं आता। जब आप शुरू से ही उनके मूल्यों को साझा नहीं करते, तो वे संगठन आपकी license पसंद पर approval stamp क्यों लगाएँ?
    • सहमत हूँ, लेकिन बस यह देखना काफी है कि OSI का खर्च कौन उठाता है: https://opensource.org/sponsors/
      corporate sponsors के लिए usage restrictions का समर्थन न करना कोई bug नहीं, बल्कि feature है।
      open source और free software की परिभाषाओं के आसपास बहुत अधिक dogmatism भी है। अगर आप इन परिभाषाओं का पालन नहीं करते, तो भीड़ इकट्ठी होकर हमला करना आसान हो जाता है, और इन परिभाषाओं को अक्सर धर्मग्रंथ की तरह माना जाता है। समर्थक इस संभावना को भी स्वीकार नहीं करना चाहते कि 2023 की वास्तविकता के हिसाब से इनमें समायोजन की ज़रूरत हो सकती है।
      टकराव से बचने के लिए नए शब्द गढ़े जाएँ तब भी, open source और free software के समर्थक अपनी ही शब्दावली पर अड़े रहते हैं और narrative को नियंत्रित करना चाहते हैं। वह भाषा उनके भीतर नकारात्मक अर्थ पैदा करने के लिए बनाई गई है।
    • मैं नहीं चाहता कि usage restrictions ज़्यादा व्यापक हों। नहीं, अगर “usage restrictions” से मतलब LGPL, GPL, AGPL द्वारा दिए गए अलग-अलग स्तर के share-alike enforcement के दायरे से बाहर कुछ और है, तो बिल्कुल नहीं।
      किसी भी उद्देश्य के लिए software चलाने की उपयोगकर्ता की आज़ादी ही freedom 0 है, और Stallman ने बहुत प्रभावशाली ढंग से समझाया है कि usage restrictions मददगार क्यों नहीं हैं: https://www.gnu.org/philosophy/programs-must-not-limit-freed...
      warranty disclaimer की तरह, free software बिना शर्त दिया जाता है। इसे अपनी मर्ज़ी से modify करने की आज़ादी तक उपहार में मिलने के बाद भी अगर कोई मुफ्त support और maintenance माँगे, तो यह बदतमीज़ी है। license बदल देने से ऐसे बदतमीज़ लोग गायब हो जाएँगे, ऐसा नहीं लगता।
    • मेरा मानना है कि ज़्यादातर लोग इतना anti-corporate होना नहीं चाहते। अगर चाहते, तो शुरू में permissive license चुना ही न होता।
      और license के बजाय दूसरे तरीकों से भी, corporations की तुलना में open source के पक्ष में ज़्यादा अनुकूल विकल्प हो सकते हैं। उदाहरण के लिए, अगर कोई गंभीर issue उठाना चाहता है, तो उसे reproduction code सार्वजनिक करना होगा।
    • मुझे ठीक से समझ नहीं आता कि इससे समस्या कैसे हल होगी। शायद वह software फिर भी business environment में इस्तेमाल होगा, और तब भी कोई अपने employer की तरफ से support माँगता रहेगा।
      80 के दशक में भी, जब support आम तौर पर मुफ्त दिया जाता था, मैंने बहुत सी कहानियाँ सुनी हैं कि कंपनियाँ pirated software के साथ भी ऐसा करती थीं। इस तरह की हरकतें कम करने वाली एकमात्र चीज़ paid support contract था।
      व्यावहारिक जवाब शायद सिर्फ यही है कि license violation पर मुकदमा किया जाए, लेकिन mid-sized company तो छोड़िए, बड़ी कंपनियों के खिलाफ भी ऐसा करने के साधन रखने वाले open source developers बहुत कम हैं।

  • “FrugalGuy” का व्यवहार अपरिपक्व और बचकाना है, लेकिन mitmproxy maintainer इससे बेहतर तरीके से, विनम्र लेकिन दृढ़ स्वर में, ऐसा जवाब दे सकता था जिसमें गलतफ़हमी या ड्रामा की कोई गुंजाइश न हो।
    “mitmproxy license के अनुसार, यह software बिना किसी warranty के जैसा है वैसा प्रदान किया जाता है, और project maintainer इस समय अन्य प्राथमिकताओं और deliverables में व्यस्त हैं।”
    “इसलिए, केवल Github issue tracker में दिए गए बयान issue की priority तय करने के लिए पर्याप्त नहीं हैं। issue की priority बढ़ाने का एकमात्र तरीका support contract करना है, जो [here] में उपलब्ध है। शर्तों पर मैं खुशी से आगे चर्चा करूँगा।”

    • यह वास्तविक जवाब से मूल रूप से बहुत अलग नहीं लगता। बल्कि थोड़ा अधिक रूखा लगता है, हालाँकि पता नहीं यही इरादा है या नहीं। इसलिए वास्तविक जवाब की तुलना में यह अतिरिक्त क्या देता है, समझ नहीं आता।
    • मुझे वास्तविक जवाब भी विनम्र और दृढ़ लगा।
    • नहीं। वह जवाब भी मूल व्यक्ति जितना ही अजीब है। माहौल समझे बिना अनुरोध करने के बाद विनम्र जवाब पाने का कोई अधिकार नहीं बनता।

  • अगर बात engineer के 1 साल के वेतन जितनी हो, तो कुछ कंपनियों के पैमाने पर यह कुछ भी नहीं है, और ऐसा लगता है कि कुछ हफ्तों में fix किया जा सकता है, जो उचित होगा।
    या अगर सच में पैसा नहीं देना चाहते, तो अपनी कंपनी के एक engineer को कुछ महीनों के लिए लगाकर paid customers को ज़रूरी हिस्से patch करवा सकते हैं और उसे upstream में contribute कर सकते हैं।
    सुधार: engineer के 1 साल के compensation की बात मेरी सीमित और गलत हो सकने वाली estimation भर है। मैं यह कहने की स्थिति में नहीं हूँ कि इसकी सही कीमत कितनी है, लेकिन मेरा अनुमान है कि जो engineer codebase से परिचित नहीं है, उसे शायद कुछ महीनों की मेहनत लगेगी।

    • देखने से तो लगता है कि बस नया release build करना होगा। fix पहले से ही हो चुका है।
      बस, ऐसा करने पर दूसरे compliance issues आ सकते हैं, और शायद इसी वजह से उन्होंने ऐसा नहीं किया। बेशक, यह open source project की समस्या नहीं है।

  • https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...

    • OP द्वारा लिंक किया गया follow-up email पूरी तरह सीमा पार कर गया था, लेकिन यह GitHub post अपने आप में आपत्तिजनक नहीं लगता। “पैसे दो” वाला जवाब भी ठीक था।
      बस “क्या अगले release की कोई target date है?” पूछना समस्या नहीं है, क्योंकि यह माँग नहीं है।
      “हम इंतज़ार करने के पक्ष में अपनी internal logic बनाना चाह रहे हैं, इसलिए हमें कोई target date चाहिए” में “चाहिए” ऐसा पढ़ा जाता है कि यह mitmproxy developers से माँग नहीं, बल्कि दूसरे लोग उससे माँग कर रहे हैं।
      इस comment में वह एक request करते हुए उसके commercial और personal motives समझा रहा है। email में वापस आकर extortion जैसे शब्द इस्तेमाल करने तक इसमें कोई समस्या नहीं थी।
    • क्या किसी खास व्यक्ति की पहचान महत्वपूर्ण है?
      मूल पोस्ट में संदर्भ और employer दोनों थे। साफ़ है कि लेखक ने जानबूझकर इन्हें टालने की कोशिश की थी, इसलिए असली GitHub issue फैलाना भी घटिया हरकत है।
    • FrugalGuy? सच में, निरुत्तर हूँ।