npm token চুরি হলেও package সরাসরি প্রকাশ নয়—stage-only পথের সীমাও আছে
GitHub-এর ১৮ সেপ্টেম্বর ২০২৬-এর changelog অনুযায়ী, npm granular access token-এ opt-in Read and write (stage only) permission যোগ হয়েছে। এই npm stage-only token দিয়ে CI নতুন version staging-এ জমা দিতে পারবে, কিন্তু maintainer-এর 2FA approval ছাড়া সেটি registry-তে প্রকাশিত হবে না। একই ঘোষণায় bypass-2FA token দিয়ে সরাসরি প্রকাশ বন্ধ করার লক্ষ্য জানুয়ারি ২০২৭ নির্ধারণ করা হয়েছে।
ফলে token চুরি বা অপব্যবহার হলেও আক্রমণকারী শুধু credentialটির জোরে নতুন package version public করতে পারবে না। তবে এটি read-only token নয়: dist-tag সরানো এবং প্রকাশিত version deprecate করার ক্ষমতা বহাল থাকে। বিদ্যমান token-গুলোর permission-ও স্বয়ংক্রিয়ভাবে stage-only হয়নি।
CI এখন release নয়, pending stage তৈরি করবে
Stage-only ব্যবস্থায় automation artifact প্রস্তুত ও upload করবে, আর প্রকাশের সিদ্ধান্ত থাকবে maintainer-এর হাতে। Release job-এ npm publish-এর বদলে npm stage publish চালালে versionটি pending stage হিসেবে জমা হয়; approval শেষ না হওয়া পর্যন্ত ব্যবহারকারীরা সেটি registry থেকে install করতে পারেন না।
npm-এর stage-only token নথিতে বলা হয়েছে, এই credential দিয়ে সরাসরি npm publish চালালে registry E_STAGE_REQUIRED error ফেরায়—token-এ Bypass 2FA সক্রিয় থাকলেও। Maintainer npm stage list দিয়ে অপেক্ষমাণ release দেখতে, npm stage view বা npm stage download দিয়ে artifact পরীক্ষা করতে এবং OTP-সহ npm stage approve চালিয়ে প্রকাশ করতে পারেন; বাতিল করার command হলো npm stage reject।
এই boundary artifact নিরাপদ বা প্রত্যাশিত—এমন নিশ্চয়তা দেয় না। চুরি হওয়া token দিয়ে ক্ষতিকর candidate stage করা সম্ভব; reviewer সেটি শনাক্ত না করে অনুমোদন করলে versionটি প্রকাশিত হবে। পরিবর্তনটি তাই automated publication থামায়, build integrity যাচাই করে না।
পুরোনো release pipeline বদলাবে যেভাবে
Migration-এর মূল পরিবর্তন command প্রতিস্থাপনে সীমাবদ্ধ নয়। কোন workflow ও package-এ direct-publish credential আছে, কারা staged artifact পরীক্ষা করবেন এবং approval বিলম্বিত হলে release-এর অবস্থা কীভাবে বোঝানো হবে—এসবও নতুন flow-তে নির্দিষ্ট করতে হবে।
- বর্তমানে npm publish চালানো workflow, ব্যবহৃত secret এবং সেই token-এর package বা scope access শনাক্ত করতে হবে।
- প্রয়োজনীয় package বা scope-তেই সীমাবদ্ধ Read and write (stage only) token তৈরি করে CI secret বদলাতে হবে।
- Release job-এ npm stage publish বসাতে হবে; build ও test সফল হওয়াকে আর প্রকাশ সম্পন্ন হওয়ার সংকেত ধরা যাবে না।
- Maintainer-এর review ও 2FA approval ধাপ নির্ধারণ করতে হবে, সঙ্গে অনুপযুক্ত candidate-এর জন্য reject পথ রাখতে হবে।
- নতুন flow যাচাইয়ের পর পুরোনো direct-publish token revoke করতে হবে; না হলে সেটি staging boundary এড়িয়ে যাওয়ার বিকল্প credential হিসেবে থেকে যাবে।
Kaleido Field-এর ১৯ সেপ্টেম্বরের স্বাধীন পর্যালোচনা opt-in status ও বিদ্যমান token অপরিবর্তিত থাকার পাশাপাশি staged publishing-এর জন্য publish access, account-এ 2FA, npm CLI 11.15.0 বা পরবর্তী এবং Node.js 22.14.0 বা পরবর্তী সংস্করণের প্রয়োজনীয়তা নথিবদ্ধ করেছে। তাই শুধু secret বদলে পুরোনো runner image রেখে দিলে migration সম্পূর্ণ নাও হতে পারে।
সমর্থিত OIDC workflow-এর ক্ষেত্রে trusted publisher বিন্যাস দীর্ঘমেয়াদি publishing secret বাদ দেওয়ার পৃথক পথ। Stage-only token token-নির্ভর automation-কে staging পর্যন্ত সীমিত করে, কিন্তু credential সংরক্ষণ ও rotation-এর প্রয়োজন দূর করে না।
Rollback approval-এর আগে, প্রকাশের পরে নয়
ভুল version, অসম্পূর্ণ artifact বা অপ্রত্যাশিত dependency approval-এর আগে ধরা পড়লে pending stage reject করে সংশোধিত build আবার জমা দেওয়া যায়। এতে ভুল candidate public version না হওয়ায় সেটি সরানো বা সঙ্গে সঙ্গে corrective patch প্রকাশের পরিস্থিতি এড়ানো সম্ভব।
কিন্তু maintainer approval দেওয়ার পর version registry-তে চলে গেলে stage-only permission কোনো rollback ব্যবস্থা দেয় না। তখন ঘটনাটি অন্য published release-এর মতোই সামলাতে হবে; stage queue কেবল publication-এর আগের সিদ্ধান্তবিন্দু।
Token ফাঁস হওয়ার সন্দেহে তাই শুধু নতুন public version খোঁজা যথেষ্ট নয়। Credential revoke বা rotate করার পাশাপাশি pending stages, সাম্প্রতিক dist-tag পরিবর্তন এবং deprecation activity পরীক্ষা করা দরকার, কারণ ওই কাজগুলো সরাসরি publication ছাড়াই package ব্যবহারকারীদের প্রভাবিত করতে পারে।
কোন ঝুঁকি কমল, কোনটি রয়ে গেল
- সরাসরি নতুন version প্রকাশ: চুরি হওয়া stage-only token একা এই কাজ করতে পারে না; maintainer approval ও 2FA প্রয়োজন।
- ক্ষতিকর candidate জমা: tokenধারী stage queue-তে artifact পাঠাতে পারে, তাই review ধাপটি আনুষ্ঠানিক অনুমোদনে পরিণত হলে সুরক্ষা দুর্বল হবে।
- Dist-tag পরিবর্তন: tokenটি tag সরাতে পারে, ফলে কোন বিদ্যমান version সাধারণ install-এ পাওয়া যায় তা বদলানোর ঝুঁকি থাকে।
- Version deprecation: প্রকাশিত version-এ deprecation বার্তা বসানোর write ক্ষমতাও বহাল থাকে।
- Account ও build compromise: দখল হওয়া maintainer account, হারানো 2FA control, ক্ষতিকর source বা বদলে যাওয়া build output এই permission নিজে শনাক্ত করে না।
অর্থাৎ “stage-only” নামটি নতুন version প্রকাশের পথকে বর্ণনা করে, package-এর সব write action-কে নয়। Token-এর package ও scope যত সংকীর্ণ হবে, compromise-এর সম্ভাব্য ক্ষেত্র তত সীমিত হবে; তবু credentialটিকে অন্য write token-এর সমান সংবেদনশীল ধরে audit করতে হবে।
২০ সেপ্টেম্বর ২০২৬ পর্যন্ত নতুন permission ব্যবহারযোগ্য হলেও গ্রহণ করা ঐচ্ছিক। নিরাপত্তার নতুন boundary কার্যকর করতে দলগুলোকে token, CI command, review দায়িত্ব ও পুরোনো credential—চারটিই বদলাতে হবে; approval latency, জরুরি release এবং বহু package-এর সমন্বিত প্রকাশে এই flow-এর বাস্তব প্রভাব এখনো প্রতিটি প্রকল্পকে নিজস্ব pipeline-এ নির্ধারণ করতে হবে।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।