এআই ও অটোমেশন

npm package-এ ১০টি trusted publisher—একটি মিললেই release অনুমোদিত

|লেখক: QUASA সম্পাদকীয় দল|5 মিনিটের পাঠ| 1
npm package-এ ১০টি trusted publisher—একটি মিললেই release অনুমোদিত

npm ৩ সেপ্টেম্বর ২০২৬-এ একটি package-এর জন্য একাধিক trusted-publishing configuration সাধারণভাবে উন্মুক্ত করেছে। GitHub-এর release announcement নিশ্চিত করে, configurationগুলো স্বাধীন ও additive: incoming OIDC token যেকোনো একটি entry-র identity criteria পূরণ করলেই সেই entry-তে অনুমোদিত npm publish অথবা npm stage publish action চালানো যাবে।

৩ সেপ্টেম্বরের এই সাধারণ প্রকাশের পর একটি package-এ একই সময়ে সর্বোচ্চ ১০টি trusted publisher রাখা যাচ্ছে। AiCybr-এর ৫ সেপ্টেম্বরের পর্যালোচনা একই সীমা ও any-match authorization model যাচাই করেছে। তবে শিরোনামের “release অনুমোদিত” মানে সরাসরি public release নয়: যে configuration মেলে, শুধু তার allowed action-ই অনুমোদিত হয়; stage-only entry package-কে registry-তে প্রকাশ করতে পারে না।

একটি match কী অনুমোদন করে

একই npm package-এর একাধিক স্বাধীন OIDC পরিচয়ের মধ্যে একটি মিলে নির্ধারিত action অনুমোদন করছে

প্রতিটি trusted publisher আলাদা CI identity নির্ধারণ করে—যেমন repository, workflow, environment, project বা pipeline। একই package-এর stable release GitHub Actions থেকে, prerelease GitLab CI/CD থেকে এবং migration pipeline CircleCI থেকে চালানো যেতে পারে। প্রতিটি পথের জন্য স্বতন্ত্র entry থাকায় দীর্ঘমেয়াদি npm write token ছাড়াই একাধিক বৈধ publication path রাখা সম্ভব।

এটি অগ্রাধিকারভিত্তিক rule chain নয়। কোন configuration আগে evaluate হবে, তা নিশ্চিত নয়; একটি সংকীর্ণ entry অন্য বিস্তৃত entry-কে সীমিত বা বাতিল করে না। ফলে production workflow-কে stage-only রাখলেও অন্য কোনো matching entry-তে direct publishing চালু থাকলে সেই দ্বিতীয় পথ সরাসরি package প্রকাশ করতে পারবে। Packageটির কার্যকর release authority তাই সব সক্রিয় configuration-এর অনুমোদিত পথের সমষ্টি।

OIDC match workflow-এর পরিচয় যাচাই করে, package-এর কোড নিরাপদ কি না তা নয়। Matching entry-তে direct publishing থাকলে বৈধ workflow registry-তে version পাঠাতে পারে। Entry-টি stage-only হলে একই পরিচয় কেবল staged artifact জমা দিতে পারবে; public availability-এর জন্য maintainer approval বাকি থাকবে।

১০টি entry যোগ করতে যে পরিচয় লাগবে

একটি npm package-এ পৃথক CI provider ও workflow-এর trusted publisher যোগ করা হচ্ছে

npm-এর trusted-publishing documentation অনুযায়ী, npmjs.com-এ package-এর Settings → Trusted publishing থেকে নতুন entry যোগ করা যায়। বর্তমানে GitHub-hosted Actions runner, GitLab.com shared runner এবং CircleCI cloud সমর্থিত; self-hosted runner নয়। OIDC trusted publishing-এর জন্য npm CLI 11.5.1 বা পরবর্তী এবং Node.js 22.14.0 বা পরবর্তী সংস্করণ প্রয়োজন; staged publishing-এর command চালাতে npm CLI 11.15.0 বা পরবর্তী সংস্করণ লাগে।

  • GitHub Actions: organization বা user, repository, workflow filename এবং ঐচ্ছিক environment দিতে হয়। Workflow file-টি repository-এর .github/workflows directory-তে থাকতে হবে এবং OIDC token তৈরির জন্য workflow-এ id-token: write permission প্রয়োজন।
  • GitLab CI/CD: namespace, project, top-level CI file path এবং ঐচ্ছিক environment নির্ধারণ করতে হয়। npm-এর জন্য ID token-এর audience হতে হবে npm:registry.npmjs.org।
  • CircleCI: organization ID, project ID, pipeline definition ID ও VCS origin আবশ্যিক; নির্দিষ্ট context ID দিয়ে পরিচয় আরও সীমিত করা যায়।

প্রতিটি connection আলাদাভাবে যোগ বা মুছে ফেলা যায়, কিন্তু existing connection-এর provider কিংবা আবশ্যিক identity field সম্পাদনা করা যায় না। কোনো field বদলাতে হলে entry মুছে নতুনটি তৈরি করতে হবে। npm configuration save করার সময় identity বাস্তবে যাচাই করে না; ভুল repository, filename বা environment সাধারণত publish attempt-এর সময় authentication failure হিসেবে ধরা পড়ে।

Stable, prerelease ও staging-এর permission map

নিচের mapটি npm-এর বাধ্যতামূলক policy নয়; এটি additive authorization-এর ঝুঁকি কমানোর ন্যূনতম-অধিকার বিন্যাস। মূল প্রশ্ন হলো কোন release path-এর তাৎক্ষণিক, মানবহীন প্রকাশ সত্যিই প্রয়োজন এবং কোনটি registry-তে যাওয়ার আগে থামানো যায়।

  • Stable workflow: সাধারণভাবে stage permission রাখলে release-এর আগে মানুষের approval থাকে। সম্পূর্ণ unattended release প্রয়োজন হলে শুধু এই entry-তে direct npm publish যোগ করা যায়; repository, workflow filename ও production environment যতটা সম্ভব নির্দিষ্ট রাখা দরকার।
  • Prerelease workflow: stage-only রাখলে beta বা release-candidate artifact public হওয়ার আগে maintainer পরীক্ষা করতে পারেন। Stable entry-র direct permission এখানে অনুলিপি করার প্রয়োজন নেই।
  • Staging বা migration workflow: শুধু npm stage publish দেওয়া হলে নতুন provider বা pipeline artifact জমা দিতে পারবে, কিন্তু একা public version ছাড়তে পারবে না।

এখানে কোনো deny rule নেই। উদাহরণ হিসেবে, staging.yml entry stage-only হলেও পুরোনো release.yml entry-তে direct publishing চালু থাকলে release.yml এখনো সরাসরি প্রকাশ করতে পারবে। তাই একটি নতুন entry আলাদাভাবে পরীক্ষা করলেই audit সম্পূর্ণ হয় না; সব entry-র identity criteria ও allowed action পাশাপাশি মিলিয়ে দেখতে হয়। একই repository বা workflow-কে আংশিকভাবে overlap করা দুটি entry বিশেষভাবে গুরুত্বপূর্ণ, কারণ অপেক্ষাকৃত বিস্তৃত entry সংকীর্ণটির restriction এড়িয়ে আলাদা অনুমোদিত পথ তৈরি করতে পারে।

Stage-only পথে মানুষের approval কোথায় থাকে

CI থেকে staged npm package জমা হওয়ার পর scan ও maintainer approval-এর অপেক্ষা

৩ সেপ্টেম্বর থেকে তৈরি নতুন trusted-publisher configuration স্বয়ংক্রিয়ভাবে npm stage publish permission পায়; direct npm publish আলাদাভাবে opt in করতে হয়। CI থেকে npm stage publish চালালে matching OIDC identity artifact staging queue-তে পাঠাতে পারে, কিন্তু version সঙ্গে সঙ্গে installable হয় না। Malware scan চলার সময় approval control নিষ্ক্রিয় থাকে এবং scan শেষ হওয়ার পর maintainer সিদ্ধান্ত নিতে পারেন।

Staged version প্রকাশ করতে maintainer-কে CLI অথবা npmjs.com থেকে 2FA ব্যবহার করে approve করতে হয়। Traditional token-ভিত্তিক বিকল্প publish path বন্ধ করতে package-এর Publishing access-এ “Require two-factor authentication and disallow tokens” নির্বাচন করা যায়। এই setting প্রচলিত npm token আটকায়, trusted publisher-এর OIDC token নয়। Private dependency install করার জন্য workflow-এ আলাদা read-only credential প্রয়োজন হতে পারে, কারণ trusted publishing শুধু publish ও stage operation authenticate করে।

পুরোনো entry-র default এক নয়। ২০ মে ২০২৬-এর আগে তৈরি configuration আগের direct-publish আচরণ ধরে রাখে; ৩ সেপ্টেম্বরের আগে তৈরি পরবর্তী configuration-এ বর্তমান permission model ব্যবহার করার সময় অন্তত একটি allowed action স্পষ্টভাবে বেছে নিতে হয়। তাই নতুন stage-first default দেখে পুরোনো package-কে নিরাপদ ধরে নেওয়া যাবে না। বর্তমান অবস্থায় সর্বোচ্চ ১০টি connection ও তিনটি cloud CI environment-ই সমর্থিত, আর অতিরিক্ত provider ও self-hosted runner support-এর নির্দিষ্ট rollout date প্রকাশ করা হয়নি।

আরও পড়ুন:

শেয়ার করুন:

আমাদের নিউজলেটার নিন

সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।

0