ImageMagick का Windows इंस्टॉलर अब साइन नहीं किया जाएगा

 (github.com/ImageMagick)
1 पॉइंट द्वारा GN⁺ 2023-10-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ImageMagick ने घोषणा की कि 28 अक्टूबर 2023 को उसका मौजूदा code signing certificate expire हो जाएगा, और उसे LeaderSSL द्वारा sponsor किया जाने वाला certificate अब नहीं मिल पाएगा
  • जून 2023 से CA/B Forum ने OV code signing private key को FIPS 140-2 Level 2 या Common Criteria Level EAL4+ certified device में store करना अनिवार्य कर दिया, जिससे private key export करके GitHub Actions में इस्तेमाल करने का तरीका बंद हो गया
  • असर सिर्फ .exe installer तक सीमित नहीं है, बल्कि code signing certificate से sign किए जाने वाले सभी binaries पर लागू है
  • चर्चा में Digicert का सालाना 629 डॉलर वाला certificate, SignPath, Azure Key Vault और AzureSignTool, Azure Code Signing, self-signing जैसे विकल्प सामने आए; इनमें से कुछ में GitHub Actions integration या AppVeyor requirement जैसी सीमाएँ हैं
  • ImageMagick ने 6 नवंबर 2023 को Azure Code Signing इस्तेमाल करने का फैसला किया, जिसके बाद binaries को फिर से sign करना संभव हो गया

Certificate expire होने और signing बंद होने की समस्या

  • ImageMagick maintainer ने घोषणा की कि 28 अक्टूबर 2023 को वर्तमान में इस्तेमाल हो रहा code signing certificate expire हो जाएगा
  • कई वर्षों तक LeaderSSL ने code signing certificate sponsor किया था, लेकिन अब वे sponsorship जारी नहीं रख पाएँगे
  • जून 2023 से CA/B Forum requirements बदल गईं, और OV code signing private key को इनमें से किसी एक में store करना जरूरी हो गया
    • FIPS 140-2 Level 2 certified device
    • Common Criteria Level EAL4+ certified device
  • इस requirement के कारण ImageMagick अब code signing certificate और private key को export करके GitHub Actions में इस्तेमाल करने वाला पुराना तरीका जारी नहीं रख सकता

जरूरी विकल्प और लागत

  • maintainer ने नए तरीके के तौर पर दो विकल्प बताए
    • अपना GitHub agent और hardware token इस्तेमाल करना
    • GitHub के साथ integrate होने वाला cloud-based signing solution इस्तेमाल करना
  • पसंदीदा तरीका GitHub के साथ integrate होने वाला cloud solution है
  • उस समय maintainer ने कहा कि Digicert ही एकमात्र विकल्प जैसा दिखता है, और Digicert code signing certificate एक साल के लिए 629 डॉलर का है, taxes अलग से हैं
  • उन्होंने अनुरोध किया कि अगर किसी organization को signed installer की जरूरत है, तो code signing certificate sponsor करें

असर का दायरा

  • एक participant ने पूछा कि असर सिर्फ .exe installer तक है या portable zip के magick.exe जैसे सभी Win32 binaries भी unsigned रहेंगे
  • maintainer ने जवाब दिया कि code signing certificate से sign किए जाने वाले सभी binaries प्रभावित होंगे

चर्चा में आए विकल्प

  • SignPath

    • एक participant ने SignPath सुझाया, और maintainer ने जवाब दिया कि वे उस company को नहीं जानते थे, लेकिन यह एक विकल्प हो सकता है
    • दूसरे participant ने अपना अनुभव साझा किया कि उन्होंने OSS project में SignPath को 2 साल से ज्यादा इस्तेमाल किया है, और सवालों पर हमेशा अच्छा response मिला
    • उसी participant ने जोड़ा कि SignPath के provenance verification तरीके के कारण signed binary या installer build के लिए AppVeyor की जरूरत होती है, और उनकी समझ के अनुसार installer .MSI format में होना चाहिए
    • SignPath की ओर से एक participant ने बताया कि free certificate पर कुछ सीमाएँ हैं
      • “SignPath Foundation” को जारी होने वाला free certificate transparent और verifiable builds मांगता है, जिसका उस समय मतलब AppVeyor था
      • GitHub Actions connector जल्द उपलब्ध होने वाला है
      • MSI, MSIX, AppX जैसे standard formats में फायदे हैं, लेकिन दूसरे installers भी process किए जा सकते हैं
      • चूँकि ImageMagick के पास registered LLC है, इसलिए ImageMagick के नाम पर बिना restrictions certificate मिल सकता है, और पहले साल को SignPath sponsor कर सकता है

  • Azure Key Vault और AzureSignTool

    • एक participant ने साझा किया कि वे GlobalSign द्वारा जारी EV code signing certificate को Azure Key Vault में रखते हैं और AzureSignTool से GitHub Actions में files sign करते हैं
    • maintainer ने जवाब दिया कि यह तरीका ज्यादा सस्ता विकल्प लगता है, और बताया कि पिछले दिन AzureSignTool इस्तेमाल करने वाला dotnet/sign भी recommend किया गया था
    • दूसरे participant ने GlobalSign और Azure Key Vault के combination से Windows installer को EV certificate से sign करने पर एक article साझा किया
    • एक participant ने कहा कि Azure Key Vault इसे support करता है और दिन में कई बार builds sign करने पर भी लागत cents के स्तर पर रहती है
    • बाद में एक अन्य participant ने जोड़ा कि जनवरी 2024 में certificate expire होने के बाद उन्हें भी यही समस्या आई; नया certificate device पर issue होना था और उसे Azure Key Vault में move नहीं किया जा सकता था

  • Azure Code Signing

    • एक participant ने कहा कि वे Azure Code Signing पर migrate कर चुके हैं और Microsoft तथा उस team से संपर्क करने की कोशिश करेंगे
    • maintainer ने जवाब दिया कि उन्होंने AzureCodeSigningTAP को सीधे email भेजा है
    • खुद को Azure Code Signing engineer बताने वाले participant ने कहा कि यह GitHub Actions को support करता है, और जरूरत होने पर संपर्क करने को कहा

  • Self-signing

    • एक participant ने पूछा कि क्या binaries को self-sign करके public certificate users से install करवाने का तरीका consider किया गया है
    • maintainer ने जवाब दिया कि अभी इस पर विचार नहीं किया है, और चर्चा में सुझाए गए विकल्पों की समीक्षा कर रहे हैं

अंतिम फैसला

  • 6 नवंबर 2023 को maintainer ने सुझाए गए कई विकल्पों के लिए धन्यवाद देते हुए बताया कि उन्होंने Azure Code Signing इस्तेमाल करने का फैसला किया है
  • इस फैसले से ImageMagick binaries को फिर से sign कर पाने में सक्षम हो गया
  • setup process को अलग repository के article ImageMagick now uses Azure Code Signing में summarize किया गया है

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

1 टिप्पणियां

 
GN⁺ 2023-10-30
Hacker News की राय

  • eSports coaches के लिए मैंने एक open-source video player मुफ्त में बनाया, लेकिन पहली बार install करते समय warning को bypass करना पड़ता है—इस शिकायत को लगातार सुनकर दर्द समझ में आता है
    certificate की लागत दे सकता हूं, लेकिन जिस project को मैं पहले ही अपना समय देकर मुफ्त में distribute कर रहा हूं, उस पर और पैसे खर्च नहीं करना चाहता
    open-source software के लिए Let's Encrypt जैसी service हो तो अच्छा होगा, लेकिन Microsoft या Apple के नजरिए से यह लोगों को app store वाले walled garden से बाहर ले जा सकती है, इसलिए शायद उनके मुख्य हितों के खिलाफ होगी
    करीब 25 साल से software बना रहा हूं, और “security” के नाम पर अपने computer पर ownership कम होते देखना काफी कड़वा लगता है
    https://www.vodon.gg/

    • Let's Encrypt forums में भी project की शुरुआत से ही ऐसी requests आती रही हैं
      आम तौर पर जवाब यह होता है कि code-signing certificate का मकसद कानूनी पहचान का प्रमाण देना है, ताकि malware distribute करने वाले व्यक्ति को offline दंडित किया जा सके, या केवल कुछ publishers की list वाले software install करने की policy लागू की जा सके
      इसके उलट HTTPS के लिए domain validation certificate का मकसद DNS name पर control साबित करना है, जिसे automated technical तरीकों से verify किया जा सकता है और यह जरूरी नहीं कि offline identity से जुड़ा हो
      Let's Encrypt certificate यह पुष्टि करता है कि कोई key किसी खास DNS name को control करने वाले व्यक्ति के control में लगती है, लेकिन code-signing certificate यह भी verify करना चाहता है कि वह किसी खास jurisdiction में मौजूद किसी खास legal entity के representative के control में लगती है, इसलिए इसे उपयोगी ढंग से verify करने की लागत कहीं ज्यादा है
      कभी सरकार इसे automate करने का तरीका दे सकती है, लेकिन दोनों certificates क्या साबित करते हैं और उन्हें verify करने का तरीका काफी अलग है
      इससे जुड़ी लंबी चर्चा पहले से https://news.ycombinator.com/item?id=38056024 पर चल रही है
    • शायद भोली सोच हो, लेकिन समाधान काफी साफ दिखता है: certificate cost को crowdsource किया जाए, और जब तक पैसा आता रहे तभी software sign किया जाए
      अगर users सच में इतनी परवाह करते हैं, तो उन्हें cost share करने के लिए तैयार होना चाहिए; नहीं तो unsigned होना भी समस्या नहीं होना चाहिए
    • unsigned होने पर एक और परेशानी है कि Chrome भी download पर warning दिखाता है
      लगता है download count पर्याप्त हो जाने पर यह warning बंद हो जाती है
    • Windows में झंझट, ads, धोखे, tracking, forced hardware updates बहुत हैं—समझ नहीं आता लोग इसे क्यों इस्तेमाल करते हैं
      Mac इस्तेमाल करें तो ऐसी चिंताएं कम हो जाती हैं
    • utility-type apps के मामले में Microsoft Store मजाक जैसा है

  • सिर्फ cost ही समस्या नहीं है
    मैं automated release workflow से signing manage कर रहा था
    https://github.com/technion/rustypwneddownloader/blob/main/....
    नए rules के तहत यह workflow इस्तेमाल नहीं कर सकते, और build को अपने desktop पर ले जाकर hardware signing key से, non-automated और non-transparent तरीके से upload करना security improvement है—यह दावा समझना मुश्किल है

    • पसंद हो या नहीं, ज्यादातर projects के लिए यह improvement है
      पहला, file में stored private key चुपचाप चोरी हो सकती है, और तब बचने का तरीका सिर्फ revoke करना होता है
      HSM requirement की मुख्य वजह यही है; malware authors काफी समय से ऐसा करते आए हैं, और कई वजहों से revocation मुश्किल और महंगा होता है
      HSM भी चोरी हो सकता है, लेकिन उसके लिए office या घर में घुसकर चीज उठानी पड़ेगी, इसलिए पता चलने की संभावना ज्यादा है
      HSM इस्तेमाल करने के credentials भी चोरी हो सकते हैं, लेकिन उन्हें आसानी से और जल्दी बदला जा सकता है; अगर पता चले कि PIN keylog हो गया है, तो breach से recover करने के बाद सिर्फ PIN बदलना होगा, certificate revoke करने की जरूरत नहीं होगी
      दूसरा, CI में automated signing सच में risky हो सकती है
      CI system में code push कर सकने वाला कोई भी व्यक्ति आपके नाम से code signing करवा सकता है, और हो सकता है आपको पता भी न चले
      key हमेशा online रहती है, इसलिए CI system hack हो गया तो बात खत्म; और अगर ऐसा न भी हो, CI arbitrary code बहुत चलाता है और उसकी close monitoring नहीं होती, इसलिए code push कर सकने वाला हर व्यक्ति कमजोरी बन जाता है
      locally sign करने पर key को release के क्षण तक सचमुच offline रखा जा सकता है, और key वाले possession factor व credentials वाले knowledge factor के साथ two-factor authentication लगाया जा सकता है, जिससे यह काफी safe होता है
      nightly development builds, internal tools, और temporary binaries जिन्हें बाहर नहीं जाना चाहिए, उन्हें मुफ्त में self-sign किया जा सकता है
    • मैं भी बिल्कुल इसी स्थिति में हूं
      GitHub Actions secrets में OV .pfx certificate store करके उसी तरह इस्तेमाल कर रहा हूं
      मेरा certificate नवंबर 2024 में expire होगा, और अभी तय नहीं किया कि क्या करूं
      company नहीं बल्कि individual developer के रूप में certificate पाना ही काफी मुश्किल था
      फिर भी अंततः यह पैसे का मामला होना चाहिए
      original में बताया गया $629/year cloud-hosted HSM हो तो यह संभव है, और वह cost देने पर अभी इस्तेमाल होने वाले signtool या Set-AuthenticodeSignature जैसे commands से इसे GitHub Actions में चलाया जा सकता है: https://docs.digicert.com/en/software-trust-manager/ci-cd-in...
    • GitHub Actions के बारे में पक्का नहीं, लेकिन शायद local CI runner से समाधान हो जाए
      करीब 100 dollar का छोटा SFF/Atom PC लेकर उसमें hardware key लगा दें
      बदलता सिर्फ इतना है कि signing step cloud से local runner पर चला जाता है
      security के लिहाज से यह improvement है या नहीं, किस नजरिए से देखें—यह मुझे ठीक से नहीं पता
    • अगर इसकी वजह से लोग binaries पर बिल्कुल sign करना बंद कर दें, तो वह निश्चित रूप से नकारात्मक परिणाम होगा

  • यह हैरान करने वाली बात है कि ImageMagick जैसा अहम और व्यापक रूप से इस्तेमाल होने वाला project software signing जैसी ज़रूरी चीज़ के लिए $629 तक नहीं जुटा पाता
    यह इस बात का साफ़ उदाहरण है कि tech industry जिन open source projects पर बहुत निर्भर करती है, उन्हें आर्थिक रूप से ठीक से support नहीं कर पाती
    बहुत ज़्यादा value देने के बावजूद, ऐसे projects अक्सर टिकाऊ बने रहने लायक पर्याप्त value वापस हासिल नहीं कर पाते
    यह एक ठंडी reminder है कि open source योगदानों को देखने और उनका मूल्यांकन करने के तरीके में बड़ा बदलाव चाहिए

    • मेरे हिसाब से समस्या $629 खुद नहीं है, बल्कि यह है कि लोगों को ऐसी चीज़ पर पैसा खर्च करने के लिए मजबूर किया जा रहा है जिसे बहुत से लोग बिल्कुल भी “ज़रूरी” नहीं मानते
      असल सवाल यह है कि यह security की समस्या है या “security” के नाम पर पैसे देकर ही हिस्सा ले सकने वाला market थोपने की समस्या
    • यह साफ़ नहीं है कि ImageMagick project को Microsoft को पैसा क्यों देना चाहिए
      बल्कि उल्टा होना चाहिए, ऐसा लगता है
    • इसे tech industry की open source को funding न दे पाने की विफलता माना जा सकता है, लेकिन मैं इसे ऐसे security system की विफलता मानता हूं जो आर्थिक gatekeeping के बिना उपलब्ध नहीं कराया जा सका
      $629 कोई मामूली रकम नहीं है
    • मुफ़्त में बनाई गई चीज़ distribute करने के लिए $629 देना पड़े—इसे सामान्य बात के रूप में स्वीकार नहीं किया जा सकता
      यह Microsoft ने Windows ecosystem में खुद पैदा की हुई स्थिति है
    • free software freedom के बारे में है
      Microsoft या उसके partners को किराया देने के बारे में नहीं

  • मेरा desktop text editor KeenWrite Windows binaries को sign करने के लिए Wine, rcedit-x64.exe, osslsigncode और shell scripts का इस्तेमाल करता है
    पहले rcedit-x64.exe binary में पहचान से जुड़ी जानकारी जोड़ता है
    https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/installe...
    उसके बाद osslsigncode certificate apply करता है
    https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/scripts/...
    जैसा पहले कहा, zero-dollar revenue वाले open source project को Windows पर distribute करने के लिए पैसा देना पड़े, तो यह मेरे computer पर मेरे ownership को कम करने जैसा है

    • वैसे, इस तरीके से certificate renew नहीं किया जा सकेगा
      अब यह HSM-based होना चाहिए

  • Windows और macOS दोनों पर application signing के साथ नरक झेला है, और यह लगातार और खराब हो रहा है
    सबसे पहले तो यह चीज़ किसी भी चीज़ को web app के रूप में देने का मन कराती है
    browser कई मायनों में कहीं बेहतर experience देता है, और security भी अच्छी तरह integrated experience है, जबकि 25 साल पुराने operating systems security को बाद में चिपकाई गई चीज़ जैसा महसूस कराते हैं
    Apple के अंदर शायद किसी को फर्क नहीं पड़ेगा, लेकिन अगर यही hardware-software monopoly को तोड़ने वाली दरार बन जाए तो काफी मज़ेदार होगा
    दूसरी बात, मुझे हैरानी है कि कोई third party इस तरह की signing को service के रूप में क्यों नहीं दे सकती
    technically मैं जितने apps sign कर सकता हूं, उसकी कोई limit तो नहीं है, है ना?
    user के नज़रिए से, certificate मेरे नाम के बजाय OS द्वारा trusted ABC Corp के नाम से signed हो तो यह समस्या क्यों है, यह भी समझ नहीं आता
    chain में कहीं कुछ revoke किया जा सकता है, लेकिन technically यह संभव लगता है, और यह भी सोचता हूं कि क्या किसी EULA में, जिस पर मैंने बिना ध्यान दिए agree किया था, इसे explicitly ban किया गया है

    • Pianojacq में हम बिल्कुल इसी decision process से गुज़रे, और कई चीज़ें कहीं मुश्किल हो गईं, खासकर database work
      फिर भी result से मैं सच में खुश हूं और users भी शायद ऐसे ही हैं
      मज़ेदार बात यह है कि हाल ही में किसी ने मुझे इसे try करने की सलाह दी, और जब उसे पता चला कि मैं इसका main author हूं तो वह काफी हैरान हुआ
    • शायद यह liability issue बन जाएगा
      इस scenario में क्या कोई भी चीज़ आंख बंद करके sign कर दी जाएगी? अगर हां, तो यह साफ़ तौर पर अच्छा नहीं है
      alternative है लंबी review और audit process, लेकिन अगर कुछ बचकर निकल गया तो फिर भी signer को ही नुकसान होगा
    • WASM और WebGPU browser और native के बीच performance gap को कम कर रहे हैं
      अगर बात device driver की नहीं है, तो हम उस point के करीब पहुंच रहे हैं जहां client-side browser में इस्तेमाल के लिए recompile किया जा सके

  • हमारी company में हाल ही में यही समस्या आई, और requirements बदलने का पता तब चला जब हम मौजूदा provider से certificate renew नहीं कर पाए
    अब Windows code signing कैसे करनी है, इस पर जानकारी हैरान करने वाली हद तक कम है
    हम physical device इस्तेमाल नहीं करना चाहते थे, और पूरी तरह remote team के लिए यह practical नहीं है
    आखिरकार हमने Digicert के साथ Azure KeyVault इस्तेमाल करने का फैसला किया
    Comodo, यानी Sectigo, मुझे पसंद नहीं है
    इस combination को सच में चलाने के बारे में जानकारी बहुत कम है, और यह test करने से पहले ही कि यह काम करेगा या नहीं, करीब $600 खर्च करने पड़ते हैं
    configuration पूरा करने के बाद यह ठीक चलता है
    Azure के जरिए signing वाला नया setup CI system में private key store करने से ज़्यादा secure है
    लेकिन मैंने कभी नहीं सोचा था कि Windows app signing macOS या iOS signing से ज़्यादा मुश्किल होगी

    • Microsoft में कहीं दो sales reps इसे पढ़कर high-five कर रहे होंगे
      mission accomplished
    • मुझे लगता है कि इसे कुछ हद तक मुश्किल और महंगा बनाना intentional design भी हो सकता है
    • अगर आप यह लिखकर बता सकें कि आपने इसे कैसे configure किया, तो अच्छा होगा
      जैसा आपने कहा, जानकारी की कमी है, इसलिए मेरे समेत कई लोगों के लिए उपयोगी होगा

  • जवाबों में से एक में आए SignPath(https://signpath.org) को किसी ने इस्तेमाल किया है या नहीं, जानना चाहता हूं
    website पर लिखा है “SignPath Foundation provides reliable code signing for Open Source projects.”
    अगर यह legitimate service है, तो उपयोगी option हो सकता है

    • vim और transmission इसे वापस link कर रहे हैं, यह देखकर legitimate लगता है
      अभी “foundation” SignPath company चलाती है, लेकिन वे कहते हैं कि उम्मीद है किसी दिन foundation expand होकर independent और community-run रूप लेगी

  • “Developers, developers, developers!” कहाँ गया, ऐसा लगता है
    बड़ी tech कंपनियों में एक बात आम दिखती है: शुरुआत में वे अच्छी लगती हैं, फिर कुछ साल बाद सड़न घुसने लगती है, और अगर वे काफी लंबे समय तक टिक जाएँ तो आखिरकार परजीवी अस्तित्व में बदल जाती हैं
    Microsoft जैसी आकार की कंपनी के लिए यह असंभव नहीं होना चाहिए कि वह उस free और open source दुनिया को, जिसका वह समर्थन करने की बात करती है, अपने platform पर बिना झंझट या लागत के distribute करने का तरीका बना सके
    सुरक्षा के नाम पर पैदा की गई ऐसी रुकावटें हमेशा संयोग से revenue के लिए मददगार साबित होती हैं

    • फिर भी, अगर मैं कुछ miss नहीं कर रहा हूँ, तो समझ नहीं आता कि ImageMagick ने यह पोस्ट करने के लिए expiry के दिन तक इंतज़ार क्यों किया

  • अच्छा होगा अगर signing certificate की लागत कुल मिलाकर कम कर दी जाए
    ज्यादा से ज्यादा 10 डॉलर के आसपास काफी है
    बहुत कम लोगों द्वारा इस्तेमाल किए जाने वाले specialized software के लिए मौजूदा लागत को justify नहीं किया जा सकता
    इसके इतना महँगा होने की जो वजह सोच में आती है, वह बस इतनी है कि रकम इतनी बड़ी हो कि चोरी हुए card का असली owner उसे notice कर ले
    इसका मतलब यह हो सकता है कि यह अपने-आप में एक तरह का author verification है
    अगर ऐसा है, तो 3 महीने बाद कुछ या पूरा पैसा refund कर देना चाहिए, ऐसा लगता है
    verification के उद्देश्य से भी उस verification के लिए हर साल पैसे लेने की जरूरत बहुत कम दिखती है, और आखिरकार यह rent-seeking जैसा लगता है

    • Microsoft ने तो लागत पहले ही कम कर दी है
      Store, जहाँ तक याद है, one-time $19 है और recurring या annual cost नहीं है
      इसलिए यह समस्या सिर्फ Store के बाहर distribute करते समय लागू होती है
      certificates महँगे इसलिए हैं क्योंकि सरकारें digitalized नहीं हैं और cryptography को ठीक से handle नहीं करतीं, इसलिए private key के ownership को legal identity के ownership से जोड़ने में काफी manual work लगता है
      Certificate authorities को देश-वार websites पर registration details खोजनी पड़ती हैं, कई बार API नहीं होती, phone calls करनी पड़ती हैं, passport scans review करने पड़ते हैं वगैरह
      यह सब labour-intensive है, इसलिए महँगा हो जाता है
      अगर सरकारें अपना public key infrastructure चलाएँ और company registration के समय private key भी issue करें, या passports में document signing के लिए private key शामिल हो, तो यह बहुत सस्ता हो सकता है
      अफसोस कि लंबे समय से इस दिशा में कोई प्रगति नहीं हुई, और जिन कुछ देशों ने national public key infrastructure के साथ प्रयोग किया था, उनमें से अधिकांश ने उसे छोड़ दिया
      अमेरिका ने Department of Defense के बाहर बड़े पैमाने पर government public key infrastructure की कोशिश कभी नहीं की, इसलिए अमेरिकी software companies को भी smartcard support अच्छा बनाने की ज्यादा जरूरत महसूस नहीं हुई
      mainstream operating systems में मजबूत support नहीं है और standards की भी कमी है
      इसके अलावा certificate consumers Microsoft और CA/Browser Forum द्वारा certificate authorities पर लगाई गई भारी operational burden भी है
      इसकी भी लागत आती है
      annual fee का मकसद लागत को समय के साथ बाँटना है
      certificate authority को पहली बार certificate issue करते समय 1 साल की fee से ज्यादा खर्च पड़ता है, लेकिन अगर वे मान लें कि user इसे कई साल इस्तेमाल करेगा, तो वे break-even पार कर सकते हैं और थोड़ा profit कमा सकते हैं

  • https://www.gnu.org/philosophy/right-to-read.en.html
    जितना ज्यादा जीता हूँ, उतना ही महसूस होता है कि RMS आधुनिक युग के Cassandra थे