GitHub-এ SHA-1 HTTPS বন্ধ—পুরোনো Git client এখন connection হারাতে পারে
GitHub ১৫ সেপ্টেম্বর ২০২৬-এ নির্ধারিত সূচি অনুযায়ী github.com ও partner CDN-এ HTTPS-এর জন্য SHA-1 support বন্ধ করেছে। GitHub-এর সমাপ্তির ঘোষণায় বলা হয়েছে, পরিবর্তনটি GitHub Enterprise Cloud এবং GitHub Enterprise Cloud with Data Residency-তেও কার্যকর হয়েছে; GitHub Enterprise Server বা GHES এতে প্রভাবিত নয়।
এর ফলে পুরোনো browser, GitHub API ব্যবহারকারী software এবং HTTPS দিয়ে push বা pull করা Git client নিরাপদ connection তৈরি করতে ব্যর্থ হতে পারে। সরাসরি করণীয় হলো ব্যর্থ পথটি শনাক্ত করে সেই পরিবেশের Git, operating system, TLS backend বা HTTP library হালনাগাদ করা—certificate verification বন্ধ করা কিংবা SHA-1 আবার চালু করা নয়।
পরিবর্তনটি repository data নয়, HTTPS connection-এ
এই অবসানের পরিধি HTTPS/TLS connection। Client ও GitHub-এর মধ্যে নিরাপদ সংযোগ স্থাপনের সময় পুরোনো SHA-1-নির্ভর সক্ষমতা আর গ্রহণ করা হচ্ছে না। এটি Git repository-র object ID, commit hash, password hash বা commit signature বদলে দেওয়ার ঘোষণা নয়; পুরোনো repository-তে ৪০ অক্ষরের commit identifier থাকলেই তাই এই connection সমস্যার প্রমাণ হয় না।
GitHub-এর এপ্রিলের deprecation notice browser, GitHub API-সংযোগকারী software এবং HTTPS-ভিত্তিক Git push ও pull-কে প্রভাবিত পথ হিসেবে চিহ্নিত করে, ১৪ জুলাই ২০২৬-এর ০০:০০–১৮:০০ UTC brownout ও ১৫ সেপ্টেম্বরের সম্পূর্ণ অবসানের সূচি দেয় এবং github.dev-কে browser compatibility পরীক্ষার ঠিকানা হিসেবে উল্লেখ করে। একই notice-এ আধুনিক browser ও API library এবং সাম্প্রতিক Git, operating system ও সংশ্লিষ্ট component ব্যবহারের পরামর্শ দেওয়া হয়।
Authentication-এর পরে পাওয়া 401 বা 403 response, ভুল repository URL, SSO restriction কিংবা permission denied-কে তাই স্বয়ংক্রিয়ভাবে SHA-1 failure বলা যাবে না। SHA-1 compatibility সমস্যা সাধারণত authentication বা repository permission যাচাইয়ের আগেই HTTPS/TLS connection তৈরির স্তরে দেখা দেবে। DNS failure ও সাধারণ timeout-ও আলাদা কারণ হতে পারে।
Browser, API ও Git—তিন পথ আলাদা করে দেখুন
প্রথমে কোন পথে ব্যর্থতা ঘটছে তা নির্ধারণ করতে হবে। একই computer-এ browser সফল হলেও পুরোনো container-এর Git বা Java, Python কিংবা .NET-ভিত্তিক API client ব্যর্থ হতে পারে, কারণ এগুলো একই TLS implementation ব্যবহার নাও করতে পারে। আবার Git সফল হওয়া মানেই API integration বা HTTPS-ভিত্তিক release download-ও সফল হবে, এমন নয়।
- Browser: যে browser নিয়ে সন্দেহ, সেটি দিয়েই github.dev খুলুন। Connection error ছাড়া পৃষ্ঠা খুললে ওই browser ও তার বর্তমান network path আধুনিক HTTPS configuration সমর্থন করে; এটি অন্য runtime-এর পরীক্ষা নয়।
- Git over HTTPS: যে host, runner বা container থেকে clone, fetch, pull বা push ব্যর্থ হচ্ছে, সেখানেই operation পুনরায় চালান। Remote URL সত্যিই HTTPS কি না এবং failure connection তৈরির সময় ঘটছে কি না মিলিয়ে নিন।
- API client: production-এ ব্যবহৃত একই runtime, HTTP library, proxy ও container image থেকে GitHub API request পরীক্ষা করুন। নিজের laptop-এর browser সফল হওয়া server-side integration-এর compatibility প্রমাণ করে না।
স্বাধীনভাবে প্রকাশিত Caiu ou Não?-এর ১৬ সেপ্টেম্বরের বিশ্লেষণ ১৫ সেপ্টেম্বরের পরিবর্তন ও তার scope মিলিয়ে দেখেছে এবং Git version-এর পাশাপাশি operating system, TLS library, container base image ও corporate proxy পরীক্ষা করার পরামর্শ দিয়েছে। বিশ্লেষণটি আরও সতর্ক করেছে, certificate verification বন্ধ করলে compatibility সমস্যা মেরামত হয় না; বরং connection-এর নিরাপত্তা দুর্বল হয়।
github.dev পরীক্ষা কোথায় থামে
github.dev সফলভাবে খোলা একটি দ্রুত প্রাথমিক পরীক্ষা, কিন্তু ফলটি কেবল ব্যবহৃত browser, তার operating-system component এবং সেই মুহূর্তের network route সম্পর্কে তথ্য দেয়। এটি একই machine-এর command-line Git বা আলাদা server-side API runtime-এর জন্য সার্বিক ছাড়পত্র নয়।
Command-line Git build ও operating system অনুযায়ী ভিন্ন HTTPS library বা TLS backend ব্যবহার করতে পারে; Linux-এ OpenSSL তার একটি উদাহরণ। ফলে শুধু git --version দেখে সিদ্ধান্ত নেওয়া যথেষ্ট নয়। Git executable-এর সঙ্গে কার্যত কোন TLS library, CA store, container image ও proxy path কাজ করছে, সেটিও দেখতে হবে।
Decision tree-টি তাই সরল: github.dev-ও না খুললে আগে browser, operating system ও network intermediary পরীক্ষা করুন। Browser চললেও Git ব্যর্থ হলে Git package, HTTPS backend, CA certificates এবং command চালানো container বা runner দেখুন। Browser ও Git চললেও API integration ব্যর্থ হলে application runtime ও তার HTTP/TLS library-কে আলাদা সমস্যা হিসেবে ধরুন। শুধু corporate network-এ failure হলে HTTPS inspection proxy বা firewall-এর compatibility network administrator-কে দিয়ে যাচাই করান।
Connection ফেরাতে কোন upgrade দরকার
পুরোনো CI image বা self-hosted runner-এর ক্ষেত্রে শুধু host machine update করলেই যথেষ্ট নাও হতে পারে। কাজটি যে image-এর ভিতরে চলছে, সেখানকার Git, TLS library, CA package ও operating-system component-ও হালনাগাদ হতে হবে। Maintained base image থেকে rebuild করলে cached পুরোনো dependency থেকে যাওয়ার সম্ভাবনা কমে।
API integration-এর ক্ষেত্রে application runtime, framework ও HTTP library update করে একই execution environment থেকে ব্যর্থ request আবার চালাতে হবে। SSH remote ব্যবহার করলে Git transport সাময়িকভাবে সচল হতে পারে, কিন্তু browser, API call বা HTTPS দিয়ে asset download-এর সমস্যা তাতে মিটবে না। তাই transport বদলকে সম্পূর্ণ সমাধান বলা যাবে না।
পরিবর্তনের আগে সম্পূর্ণ error message, সময়, operating-system version, Git version এবং ব্যর্থ host বা container-এর পরিচয় সংরক্ষণ করলে কারণ আলাদা করা সহজ হয়। Update-এর পরে ঠিক যে operation ব্যর্থ হয়েছিল সেটিই আবার পরীক্ষা করুন। http.sslVerify=false বা GIT_SSL_NO_VERIFY দিয়ে certificate validation বন্ধ করা উচিত নয়; এতে error চাপা পড়লেও বিশ্বাসযোগ্য TLS connection পুনরুদ্ধার হয় না।
GHES কেন এই পরিবর্তনের বাইরে
GitHub Enterprise Server প্রতিষ্ঠানের নিজস্ব infrastructure-এ পরিচালিত deployment। ১৫ সেপ্টেম্বরের পরিবর্তনটি github.com, GitHub-এর সংশ্লিষ্ট cloud offerings এবং partner CDN-এর service boundary-তে করা হয়েছে। তাই একই দিনে কোনো GHES instance-এর connection সচল থাকা ঘোষণার সঙ্গে বিরোধপূর্ণ নয়; সেখানে সংশ্লিষ্ট administrator-এর configuration ও upgrade policy কার্যকর থাকবে।
নির্ধারিত removal এখন আর পরীক্ষা বা সাময়িক brownout নয়—GitHub সেটি সম্পন্ন করেছে। কোনো পুরোনো environment GitHub-এর সঙ্গে HTTPS connection হারালে browser, Git transport ও API runtime আলাদা করে পরীক্ষা করে অচল TLS component শনাক্ত করাই মূল কাজ। তবে প্রতিটি TLS error-কে প্রমাণ ছাড়া SHA-1 removal-এর ফল বলা যাবে না, এবং GitHub এখনো ব্যর্থ হতে পারে এমন সব client, OS বা backend-এর পূর্ণ তালিকা প্রকাশ করেনি।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।