Trusted Publishing को पैकेज भरोसे के संकेत के रूप में नहीं देखना चाहिए

 (blog.yossarian.net)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Trusted Publishing में “trust” का मतलब यह नहीं है कि इंसान किसी पैकेज पर भरोसा कर सकते हैं; यह CI/CD जैसी बाहरी machine identity और package index के बीच upload authentication संबंध को दर्शाता है
  • PyPI का implementation OIDC federation पर काम करता है और लंबे समय तक चलने वाले API tokens के बजाय छोटी अवधि और सीमित scope वाली publishing credentials जारी करता है, जिससे long-lived और over-privileged credentials के exposure में कमी आती है
  • PyPI ने 2023 में इसे सार्वजनिक किया, जिसके बाद यह npm, RubyGems, crates.io, NuGet आदि तक फैला, लेकिन data model की complexity, अलग-अलग OIDC providers की handling, और CI/CD compromise की संभावना अभी भी बनी हुई है
  • PyPI Trusted Publishing status को project page पर हरे check mark से highlight नहीं करता; इसे सिर्फ file details में साधारण Yes/No metadata के रूप में दिखाता है, ताकि इसे safety signal समझने की गुंजाइश कम हो
  • Trusted Publishing और PyPI attestations केवल upload authentication या machine identity-आधारित signing की मौजूदगी बताते हैं; जब तक उस identity पर अलग से भरोसा न किया जाए, वे package की safety या quality का आकलन नहीं कर सकते

Trusted Publishing जिस trust के दायरे को संभालता है

  • Trusted Publishing कोई ऐसा feature नहीं है जो इंसानों से कहे कि वे किसी package पर भरोसा करें; यह machine-to-machine trust को संभालने वाला authentication तरीका है
  • Trusted Publishing को इस सवाल के रूप में देखना कि इंसान भरोसा कर सकते हैं या नहीं, category mismatch है
  • मुख्य बात CI/CD workflow जैसी बाहरी machine identity और package index की project identity के बीच upload authentication के लिए trust relationship बनाना है

PyPI का Trusted Publishing structure

  • “Trusted Publishing” वह शब्द है जिसे PyPI OpenID Connect federation पर आधारित authentication method को समझाने के लिए इस्तेमाल करता है
  • PyPI ने इसे 2023 में सार्वजनिक किया, और इसके बाद npm, RubyGems, crates.io, NuGet आदि ने भी इसे अपनाया
  • शुरुआत दो समस्याओं से होती है
    • Long-lived credentials जैसे index API tokens को सुरक्षित रूप से manage करना मुश्किल है, और users के लिए minimum privileges और expiry period तय करना कठिन होता है, इसलिए वे अक्सर over-privileged set हो जाते हैं
    • कई users CI/CD platform में डालने के लिए credentials बनाते हैं, और CI/CD platforms के पास भी OIDC के जरिए किसी खास machine identity पर control साबित करने का mechanism होता है
  • User package index में CI/CD machine identity यानी Trusted Publisher को एक बार register करता है, और जब CI/CD identity token पेश करता है, तो index उसे verify करके छोटी अवधि और सीमित scope वाली publishing credentials जारी करता है

फायदे और बची हुई सीमाएं

  • छोटी अवधि और self-scoped credentials वाला तरीका PyPI users के लिए काफी सफल approach माना जाता है
    • Users उस तरीके को पसंद करते हैं जिसमें जरूरत न होने पर credentials को सीधे manage न करना पड़े
    • बड़े open source projects और companies इस property को पसंद करते हैं कि publishing permission किसी individual maintainer के बजाय source identity से जुड़ी हो
  • Trusted Publishing में भी structural complexity बची रहती है
    • PyPI के “pending publishers” उन projects की समस्या हल करते हैं जो अभी मौजूद नहीं हैं, लेकिन data model को complex बनाते हैं और सामान्य Trusted Publishing की तुलना में users के लिए ज्यादा confusing हैं
    • OIDC providers common claims के कुछ हिस्सों के अलावा claim set में अलग-अलग तरह की values डाल सकते हैं, इसलिए index को हर provider के unique format को अलग से handle करना पड़ता है
    • इसी वजह से machine identities OIDC IdPs के बीच interchangeable नहीं हैं, और यह PyPI द्वारा नए Trusted Publishing providers को धीरे-धीरे add करने की वजहों में से एक है
  • अगर CI/CD workflow compromise हो जाए, तो attacker Trusted Publishing credentials या उनके seed के रूप में काम करने वाले OIDC ID token को leak कर सकता है
    • यह उस स्थिति जैसा है जब workflow में long-lived credentials मौजूद हों, लेकिन Trusted Publishing credentials में वही scope और lifetime risk नहीं होता
    • PyPI pull_request_target जैसे आसानी से abuse किए जा सकने वाले triggers से जुड़ी machine identities के लिए token exchange से इनकार करके CI/CD compromise risk को कम करता है

यह package trust signal क्यों नहीं है

  • Trusted Publishing सिर्फ एक authentication method है; यह इस बारे में कोई जानकारी नहीं देता कि package सुरक्षित है या नहीं, quality अच्छी है या नहीं, या इस्तेमाल करने लायक है या नहीं
  • PyPI एक public index है जहां कोई भी upload कर सकता है, और कोई भी Trusted Publisher का इस्तेमाल करके upload कर सकता है
    • Trusted Publisher के जरिए भी malicious code या vulnerable code upload किया जा सकता है
    • इस मामले में यह PyPI के दूसरे upload authentication method, API token, जैसा ही है
  • PyPI में Trusted Publishing mandatory नहीं है और आगे भी mandatory नहीं हो सकता
    • Users पर Trusted Publishing थोपना engineering के लिहाज से feasible नहीं है, और तकनीकी व सामाजिक रूप से भी desirable नहीं है
    • Trusted Publishing हमेशा optional है

PyPI UI गलतफहमी कैसे कम करता है

  • PyPI सावधानी बरतता है ताकि users Trusted Publishing status को package trust signal न समझ बैठें
  • Project page पर Trusted Publishing status दिखाने वाला हरा check mark नहीं होता
  • User-controlled status के लिए हरा check mark सिर्फ उन links पर इस्तेमाल होता है जिनके बारे में PyPI प्रमाणित कर सकता है कि वे package itself वाली ही source से आए हैं
  • Verified URL सिर्फ इतना साबित करता है कि verification के समय वह URL PyPI package owner के control में था; इसका मतलब URL या project की अतिरिक्त safety नहीं है
  • किसी specific file का Trusted Publishing status file details में साधारण Yes/No value के रूप में दिखाया जाता है
    • File metadata area को user trust judgment के लिए महत्वपूर्ण जानकारी जैसा render नहीं किया जाता
    • Upload client के user agent से आए JSON blob को भी ठीक से render नहीं किया जाता

attestations से फर्क

  • यह मुद्दा PyPI की attestations से अलग है
  • attestations भी फिलहाल OIDC machine identity का इस्तेमाल करती हैं, लेकिन वे trust signal नहीं हैं
  • attestation machine identity पर signature जैसा है, लेकिन PyPI पर कोई भी upload कर सकता है, इसलिए कोई भी अपने control वाली machine identity से sign कर सकता है
  • Trusted Publisher होने का मतलब यह नहीं कि attestation जरूर मौजूद है, और attestation होने का मतलब यह भी नहीं कि end users किसी specific identity पर भरोसा कर सकते हैं
  • PyPI का attestation trustworthiness model भी इस बात को document करता है

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

1 टिप्पणियां

 
GN⁺ 5 시간 전
Lobste.rs की राय

  • अच्छा लेख है। Trusted Publishing और attestation (प्रमाणन) अलग-अलग failure modes के लिए अलग-अलग guarantees देते हैं, और दोनों ही उस भरोसे से अलग हैं जिसके बारे में ज़्यादातर users बात करते हैं

  • Trusted Publishing इसलिए संभव हुआ क्योंकि पिछले 15 वर्षों में कई open source projects mailing lists, Git repositories, bug trackers, build servers जैसी self-hosted व्यवस्था से centralized forges पर चले गए
    अब centralized forges की कमियां और स्पष्ट हो रही हैं, इसलिए projects फिर से self-hosting पर विचार कर रहे हैं
    2010 के दशक में सुविधा और social network effects ने projects को centralized forges की ओर धकेला था, लेकिन अब Trusted Publishing समेत projects को बांधे रखने वाले कारण कहीं ज़्यादा हो गए हैं
    Authority पर अविश्वास करो — decentralization को बढ़ावा दो
    — "The Hacker Ethics", Hackers: Heroes of the Computer Revolution (Steven Levy, 1984)

    • Trusted Publishing में lock-in नहीं है। PyPI जिन hosts से integrate कर सकता है, उन्हें शामिल करते हुए आप कभी भी कोई दूसरा authentication तरीका इस्तेमाल कर सकते हैं
      federated authentication तरीके को lock-in का एक रूप कहना थोड़ा ironic है
    • self-hosting असल में लगभग हमेशा एक niche पसंद रही है। SourceForge का उद्देश्य ही उस बोझ को अपने ऊपर लेना था
      लगभग उसी दौर में, करीब 25 साल पहले ASF भी था, लेकिन ASF में governance का बोझ भी काफी था। उससे पहले GNU project था, जो free software ideology पर ज़्यादा ज़ोर देता था और systematic project hosting service पर कम केंद्रित था। वजह यह थी कि GNU उस समय से मौजूद था जब free software projects को किन services की ज़रूरत है, इसकी स्पष्ट समझ बनी भी नहीं थी
      1990 के दशक के free software projects आमतौर पर किसी university की time-sharing service या किसी दोस्त के colocation server पर hosted होते थे। उदाहरण के लिए PuTTY या ASF से पहले Apache httpd वाला Hyperreal.org इसी तरह थे
      इतने बड़े projects कम ही होते थे कि अपने infrastructure को justify कर सकें, और सस्ती hosting भी अपेक्षाकृत हाल में ही संभव हुई है
    • self-hosted Forgejo में Trusted Publishing न कर पाने की कोई वजह है क्या? अगर है, तो शायद मैं कुछ miss कर रहा हूं