Git-এ নিরাপত্তা — signed commit, secret ফাঁস ঠেকানো আর history পরিষ্কার

১ · History একটি নিরাপত্তার জায়গা — কেন commit প্রায় মোছা যায় না

মডিউল ৯-এর আগের পর্বগুলোতে Git-এর ভেতরের কাজ দেখেছেন: object store (পর্ব ৫২ — Git-এর ভেতরে), reflog আর garbage collection (পর্ব ৫৩ — Ref, reflog আর উদ্ধার), log -S দিয়ে খোঁজা (পর্ব ৫৫ — Git দিয়ে bug খোঁজা) আর hook (পর্ব ৫৬ — Git-এর শক্তিশালী হাতিয়ার). এই সব গুণ — কিছুই সহজে না হারানো, পুরো history সবার কাছে — দৈনন্দিন কাজে আশীর্বাদ। কিন্তু নিরাপত্তার চোখে একই গুণ ঝুঁকি।

এই পর্বের ঝুঁকিগুলো পাঁচ ভাগে ভাবতে পারেন:

• Secret ফাঁস: password, API key, personal access token বা private key commit হয়ে যাওয়া। Secret একবার history-তে ঢুকলে পরের commit-এ মুছলেও পুরোনো commit থেকে পড়া যায়।
• জাল পরিচয়: কেউ অন্যের নাম-email বসিয়ে commit বা release tag বানাতে পারেন।
• History-তে হাত দেওয়া: server বা account দখল করে কোড বদলানো, পুরোনো tag সরানো।
• চাবি রাখার দুর্বলতা: token খোলা লেখায় ফাইলে, passphrase ছাড়া SSH key, সব repository-তে লেখার ক্ষমতাওয়ালা একটি token.
• Tool-এর নিজের দুর্বলতা: Git-এর bug, ভুল জায়গায় রাখা .git folder, অজানা submodule.

Public repository-তে push হওয়া key খুব দ্রুত স্বয়ংক্রিয় scanner-এর চোখে পড়তে পারে — নিরাপত্তা-গবেষক আর platform-গুলোর বিভিন্ন প্রতিবেদন এটি বারবার দেখিয়েছে; কতটা দ্রুত, তা পরিস্থিতিভেদে আলাদা। তাই এই পর্বের মূল সুর: secret কখনো commit হতে দেবেন না; হয়ে গেলে ধরে নিন ফাঁস হয়ে গেছে।

এই পর্বের সব Git আউটপুট আসল — Git ২.৫৩ (Windows) আর OpenSSH ১০.২ দিয়ে scratchpad-এর একটি খালি পরীক্ষার folder-এ চালানো। Commit hash যেন আপনার কাছেও একই আসে, তাই নাম “Rahim”, email rahim@example.com, init.defaultBranch=main, core.autocrlf=false, আর প্রতিটি commit-এর সময় GIT_AUTHOR_DATE ও GIT_COMMITTER_DATE দিয়ে এক মিনিট করে বাড়িয়ে ঠিক করা। একটি দরকারি অভ্যাস: পরীক্ষার সময় নিজের আসল config ছুঁইনি — GIT_CONFIG_GLOBAL একটি খালি পরীক্ষার ফাইলের দিকে আর GIT_CONFIG_NOSYSTEM=1. নিরাপত্তার কিছু চেষ্টা করতে চাইলে আপনিও এভাবে আলাদা জায়গায় করুন। গল্পটি একটি কাল্পনিক অনলাইন বাজার অ্যাপের।

২ · Commit-এর পরিচয় শুধু লেখা — আর স্বাক্ষর কী প্রমাণ করে

পর্ব ৮-এ (প্রথম Git repository) git config user.name আর user.email সেট করেছিলেন। Git এগুলো যাচাই করে না — কোনো server-কে জিজ্ঞেস করে না, কোনো password চায় না। যা লেখা আছে, তা-ই commit-এর author আর committer হিসেবে বসে। নিচে রহিম নিজের কম্পিউটারে, এক command-এর জন্য অন্য নাম বসিয়ে commit করলেন:

$ git config user.name
Rahim
$ git -c user.name="Nasrin" -c user.email="nasrin@example.com" commit -q -m "Add shop config"
$ git log --format="%h %an <%ae> %s"
f777349 Nasrin <nasrin@example.com> Add shop config
7f51f18 Rahim <rahim@example.com> Add README

Digital signature — এক মিনিটে

Digital signature দাঁড়িয়ে আছে public-key cryptography-র ওপর: প্রত্যেকের একজোড়া key — private key শুধু নিজের কাছে, public key সবার জন্য। Private key দিয়ে কোনো লেখার স্বাক্ষর বানানো যায়; public key দিয়ে যে কেউ যাচাই করতে পারেন যে (১) স্বাক্ষরটি ওই জোড়ার private key দিয়েই বানানো, আর (২) লেখার একটি অক্ষরও পরে বদলায়নি। গণিত আর algorithm-এর বিস্তারিত Computer Networks কোর্সের Cryptography-র মৌলিক পর্বে।

Git-এ signed commit মানে commit object-এর লেখার (tree, parent, author, committer, বার্তা) ওপর একটি স্বাক্ষর, যা commit-এর ভেতরেই gpgsig header-এ রাখা হয়। স্বাক্ষর commit-এর অংশ, তাই commit hash-ও তার ওপর নির্ভর করে। Tree আর parent hash দিয়ে যুক্ত থাকায় স্বাক্ষর পরোক্ষে পুরো snapshot আর তার আগের পুরো history-কেও ঢাকে (hash কতটা শক্ত, সে প্রশ্ন অংশ ৮-এ)।

৩ · Signed commit আর tag — SSH, GPG আর X.509

Git তিন ধরনের স্বাক্ষর বোঝে, বেছে নেওয়া হয় gpg.format config দিয়ে:

Command সব ক্ষেত্রেই একই: commit-এ বড় হাতের -S (ছোট -s শুধু Signed-off-by লাইন যোগ করে — পর্ব ১৮), tag-এ git tag -s (এটি নিজেই একটি annotated tag বানায়), দেখতে git log --show-signature, যাচাই করতে git verify-commit আর git verify-tag. প্রতিবার -S লিখতে না চাইলে commit.gpgSign true আর tag.gpgSign true.

SSH দিয়ে sign — আসল transcript

পরীক্ষার জন্য scratchpad-এ একটি ফেলে দেওয়ার মতো ed25519 key বানানো হয়েছে, passphrase ছাড়া (ssh-keygen -t ed25519 -N "" -f keys/rahim_demo). পরীক্ষা শেষে মুছে ফেলা হয়েছে। আসল key-তে অবশ্যই passphrase দেবেন (অংশ ৭)। Allowed signers ফাইলের প্রতিটি লাইন বলে “এই principal (সাধারণত email)-এর এই public key, এই কাজের (namespace) জন্য”:

$ git config gpg.format ssh
$ git config user.signingkey ../keys/rahim_demo
$ git config gpg.ssh.allowedSignersFile ../keys/allowed_signers
$ cut -c1-60 ../keys/allowed_signers
rahim@example.com namespaces="git" ssh-ed25519 AAAAC3NzaC1lZ
$ git commit -S -m "Lower delivery fee to 50"
[main a0eb0bc] Lower delivery fee to 50
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git log --show-signature -1
commit a0eb0bca05ed84e4c9a1e1737231f3778fc5e60b
Good "git" signature for rahim@example.com with ED25519 key SHA256:izkxYOtIHXekFPtahvkTxshbwIVtxZER6z3D8Y80ujs
Author: Rahim <rahim@example.com>
Date:   Tue Feb 10 10:02:00 2026 +0600

    Lower delivery fee to 50
$ git verify-commit HEAD
Good "git" signature for rahim@example.com with ED25519 key SHA256:izkxYOtIHXekFPtahvkTxshbwIVtxZER6z3D8Y80ujs
$ git verify-commit HEAD~1; echo $?
1
$ git cat-file commit HEAD | head -6
tree 08c9e41301558f6bf3107ec547bd7ed701e666e3
parent f777349c7cd01d04f4b98efc245dce566263469d
author Rahim <rahim@example.com> 1770696120 +0600
committer Rahim <rahim@example.com> 1770696120 +0600
gpgsig -----BEGIN SSH SIGNATURE-----
 U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgXV3/Y/XNOa317c0PMiAxxr4ke2
…

এবার একটি signed release tag, আর এমন একটি commit যা অচেনা key দিয়ে sign করা:

$ git tag -s v1.0 -m "Release 1.0"
$ git verify-tag v1.0
Good "git" signature for rahim@example.com with ED25519 key SHA256:izkxYOtIHXekFPtahvkTxshbwIVtxZER6z3D8Y80ujs
$ git -c user.signingkey=../keys/other_demo commit -q -S -m "Lower delivery fee to 40"
$ git verify-commit HEAD; echo $?
Good "git" signature with ED25519 key SHA256:YNtvQj73Y2JRyauX/FllEZb9k1C3ZnIPAOVFzhM4Ac8
No principal matched.
1
$ git log --format="%h %G? %s"
dcab560 U Lower delivery fee to 40
a0eb0bc G Lower delivery fee to 50
f777349 N Add shop config
7f51f18 N Add README

নিচের stepper-এ setup থেকে যাচাই পর্যন্ত প্রতিটি ধাপে কী তৈরি হয় আর কে কী জানে, তা দেখুন।

$ ssh-keygen -t ed25519 -C "rahim@example.com"
  → ~/.ssh/id_ed25519      (private, passphrase-সহ)
  → ~/.ssh/id_ed25519.pub  (public, শেয়ার করা যায়)

gpg.format      = ssh
user.signingkey = ~/.ssh/id_ed25519.pub   (agent থাকলে)
commit.gpgSign  = true                     (ঐচ্ছিক)

tree 08c9e41…
parent f777349…
author Rahim <rahim@example.com> …
committer Rahim <rahim@example.com> …
gpgsig -----BEGIN SSH SIGNATURE-----  ← নতুন
message: Lower delivery fee to 50

rahim@example.com namespaces="git" ssh-ed25519 AAAA…
nasrin@example.com namespaces="git" ssh-ed25519 AAAA…
(দলের repository-তে রাখা, review করে বদলানো)

চেনা key   → Good "git" signature for rahim@…   exit 0  (%G? = G)
অচেনা key  → Good … No principal matched.        exit 1  (%G? = U)
স্বাক্ষর নেই → (কিছু ছাপে না)                       exit 1  (%G? = N)

Platform-এর “Verified” badge

বড় hosting platform-গুলো (যেমন GitHub, GitLab) commit-এর পাশে “Verified” জাতীয় চিহ্ন দেখায়, যখন স্বাক্ষর এমন একটি key-এর সাথে মেলে যা ওই commit-এর email-ওয়ালা account-এ তোলা আছে। কিছু platform-এ একটি কড়া মোড আছে (যেমন GitHub-এর “vigilant mode”), যেখানে আপনার নামে আসা unsigned commit-কে “Unverified” দেখায় — যাতে জাল-পরিচয়ের commit চোখে পড়ে। আর branch protection-এ “শুধু signed commit গ্রহণযোগ্য” নিয়ম বসানো যায়। নাম আর নিয়ম লেখার সময়ের, platform-ভেদে আলাদা — documentation মিলিয়ে নিন। একটি সূক্ষ্মতা: platform নিজে web interface-এ merge বা squash করলে commit-টি প্রায়ই platform-এর নিজের key-তে sign হয়।

৪ · Secret ফাঁস ঠেকানো — স্তরে স্তরে পাহারা

সবচেয়ে সস্তা ঘটনা হলো যা ঘটেই না। Secret যেন repository-তেই না ঢোকে, তার জন্য একটির ওপর আরেকটি স্তর বসানো হয় — নিরাপত্তায় একে বলে defense in depth. কোনো একটি স্তর নিখুঁত নয়; মিলে তারা ঝুঁকি কমায়।

• Secret কোডের বাইরে: কোডে key না লিখে environment variable থেকে পড়া (os.environ["PAYMENT_API_KEY"]). Local কাজে মান থাকে একটি .env file-এ, যা .gitignore-এ রাখা আর তার বদলে খালি মানের .env.example commit করা — পর্ব ১০-এ (.gitignore, .gitattributes আর git config) দেখেছেন। মনে রাখুন, .gitignore আগে থেকে track হওয়া ফাইলকে থামায় না।
• Secret manager: production-এ secret রাখা হয় একটি secret manager-এ (cloud provider-এর vault বা নিজস্ব ব্যবস্থা), যা প্রবেশাধিকার, log আর নিয়মিত বদল সামলায়। নকশার দিকটি System Design কোর্সের নিরাপত্তার নকশা পর্বে।
• Commit-এর আগে scanner: একটি pre-commit hook staged পরিবর্তনে secret-এর ধাঁচ খোঁজে, পেলে commit থামায়। Hook কীভাবে কাজ করে, পর্ব ৫৬-এ। প্রচলিত open-source tool-এর মধ্যে আছে gitleaks, detect-secrets, TruffleHog — প্রত্যেকের নিয়ম, option আর license আলাদা, আর বদলায়; ব্যবহারের আগে নিজের documentation দেখুন।
• Push protection: কিছু platform push গ্রহণের আগেই পরিচিত ধরনের secret খোঁজে আর push আটকায় (লেখার সময়ে GitHub-এ “push protection” নামে; অন্য platform-এ আলাদা নাম ও শর্ত)। Hook client-এ বন্ধ করা যায়, server-এর পাহারা নয় — তাই দুটোই দরকার।
• CI আর পুরো history scan: pipeline-এ প্রতিটি pull request আর নির্দিষ্ট সময় পরপর পুরো history scan; CI-তে secret কীভাবে রাখবেন, পর্ব ৫৮-এ (Continuous integration). Code review-এর নিরাপত্তা-চোখ পর্ব ৪৪-এ (Code review).
• শেষ ভরসা — বদলানো: সব স্তর ফসকালে secret বাতিল করে নতুন বানানো (secret rotation). অংশ ৫-এ।

Scanner ভেতরে কীভাবে কাজ করে — একটি খেলনা scanner

বেশিরভাগ secret scanner দুটি কৌশল মেশায়। এক, নির্দিষ্ট ধাঁচ (regex): অনেক provider-এর key-এর শুরুতে পরিচিত prefix থাকে আর দৈর্ঘ্য নির্দিষ্ট; যেমন AWS-এর access key ID-র প্রচলিত রূপ AKIA + ১৬টি বড় হাতের অক্ষর বা অঙ্ক। দুই, এলোমেলোতা মাপা: মানুষের লেখা শব্দে কিছু অক্ষর বারবার আসে, কিন্তু এলোমেলো token-এ অক্ষর ছড়ানো থাকে। এই ছড়ানো-ভাব মাপে Shannon entropy:

এখানে p(c) হলো লেখায় অক্ষর c-এর অনুপাত। সব অক্ষর এক হলে H = ০; ১৬ রকম অক্ষর সমানভাবে থাকলে H = log₂16 = ৪. নিচের খেলনা scanner একটি diff-এর শুধু যোগ হওয়া (+) লাইন দেখে, দুটি regex নিয়ম আর ২০ অক্ষরের বেশি লম্বা টুকরোর entropy মাপে। সব মান বানানো।

import re, math
# Toy secret scanner. ALL values below are FAKE, made up for this lesson.
DIFF = """+DB_HOST=localhost
+AWS_ACCESS_KEY_ID=AKIAFAKEEXAMPLE00001
+PAYMENT_API_KEY=FAKE_sk_test_9fQ2xLm4Rt7Vb1Nz
+password = "changeme"
+COMMIT_ID=3f9a1c2e8b7d6a5f4e3c2b1a0f9e8d7c6b5a4f3e
+GREETING=assalamualaikum_bandhu
-OLD_KEY=removed_line_is_not_scanned"""
RULES = [("aws-style-key-id", re.compile(r"\bAKIA[0-9A-Z]{16}\b")),
         ("password-assignment", re.compile(r"(?i)password\s*=\s*\"[^\"]+\""))]
TOKEN = re.compile(r"[A-Za-z0-9_+/=-]{20,}")
def entropy(s):
    n = len(s)
    return -sum(s.count(c) / n * math.log2(s.count(c) / n) for c in set(s))
def scan(diff, threshold=4.0):
    found = []
    for no, line in enumerate(diff.splitlines(), 1):
        if not line.startswith("+"):
            continue                      # only added lines
        for name, rx in RULES:
            if rx.search(line):
                found.append((no, name, line[1:40]))
        for tok in TOKEN.findall(line.split("=", 1)[-1]):
            h = entropy(tok)
            if h >= threshold:
                found.append((no, f"high-entropy {h:.2f}", tok[:24]))
    return found
for no, rule, text in scan(DIFF):
    print(f"line {no}: {rule:22} {text}")

line 2: aws-style-key-id       AWS_ACCESS_KEY_ID=AKIAFAKEEXAMPLE00001
line 3: high-entropy 4.46      FAKE_sk_test_9fQ2xLm4Rt7
line 4: password-assignment    password = "changeme"

Entropy-র সীমা নিজে মেপে দেখুন — কোন সীমায় কোনটি ধরা পড়ে, আর কোথায় false positive শুরু হয়:

// Shannon entropy in bits per character: H = -sum p(c) * log2 p(c)
// All "tokens" below are FAKE examples made up for this lesson.
function entropy(s) {
  const count = {};
  for (const c of s) count[c] = (count[c] || 0) + 1;
  let h = 0;
  for (const c in count) {
    const p = count[c] / s.length;
    h -= p * Math.log2(p);
  }
  return h;
}
const samples = [
  ["random-looking token", "FAKE_sk_test_9fQ2xLm4Rt7Vb1Nz"],
  ["git commit id (hex)", "3f9a1c2e8b7d6a5f4e3c2b1a0f9e8d7c6b5a4f3e"],
  ["uuid (not secret)", "7c9e6679-7425-40de-944b-e07fc1f90ae7"],
  ["normal words", "delivery_fee_for_dhaka_city"],
  ["weak password", "changeme"],
  ["same letter", "aaaaaaaaaaaaaaaaaaaa"],
];
const flag = (s, h, t) => (s.length >= 20 && h >= t ? "FLAG" : "ok  ");
console.log("T=4.0 T=3.5  H    len  sample");
for (const [label, s] of samples) {
  const h = entropy(s);
  console.log(`${flag(s, h, 4.0)}  ${flag(s, h, 3.5)}   ${h.toFixed(2)} ${String(s.length).padStart(3)}  ${label}`);
}
console.log("max for hex = log2(16) =", Math.log2(16));
console.log("max for base64 = log2(64) =", Math.log2(64));

T=4.0 T=3.5  H    len  sample
FLAG  FLAG   4.46  29  random-looking token
ok    FLAG   3.92  40  git commit id (hex)
ok    FLAG   3.66  36  uuid (not secret)
ok    FLAG   3.72  27  normal words
ok    ok     2.75   8  weak password
ok    ok     0.00  20  same letter
max for hex = log2(16) = 4
max for base64 = log2(64) = 6

৫ · Secret commit হয়ে গেলে — আগে বাতিল, পরে history

ধরুন রহিম ভুল করে .env commit করেছেন, পরের commit-এ সেটি track থেকে সরিয়ে .gitignore-এ দিয়েছেন। Working tree আর সর্বশেষ commit-এ ফাইল নেই। কিন্তু history? পর্ব ৫৫-এর log -S (যে commit-এ লেখাটি যোগ বা বাদ হয়েছে) দিয়ে খুঁজলেন:

$ git ls-files
.gitignore
README.md
app.py
$ git log --oneline
b109503 Lower fee to 50
93fa95a Stop tracking .env
1799e4e Add app and settings
c6c1dc3 Add README
$ git log -p -S "PAYMENT_API_KEY" --format="%h %s" -- .env
93fa95a Stop tracking .env

diff --git a/.env b/.env
deleted file mode 100644
index 2113fdb..0000000
--- a/.env
+++ /dev/null
@@ -1,2 +0,0 @@
-DB_HOST=localhost
-PAYMENT_API_KEY=FAKE_sk_test_9fQ2xLm4Rt7Vb1Nz
1799e4e Add app and settings

diff --git a/.env b/.env
new file mode 100644
index 0000000..2113fdb
--- /dev/null
+++ b/.env
@@ -0,0 +1,2 @@
+DB_HOST=localhost
+PAYMENT_API_KEY=FAKE_sk_test_9fQ2xLm4Rt7Vb1Nz
$ git grep -n "PAYMENT_API_KEY" $(git rev-list --all)
1799e4e1869584595b12ccb62aa861ff7da3ffbf:.env:2:PAYMENT_API_KEY=FAKE_sk_test_9fQ2xLm4Rt7Vb1Nz

সঠিক ক্রম — কেন আগে বাতিল

প্রথম প্রবৃত্তি হয় history পরিষ্কার করা। কিন্তু push হয়ে থাকলে ধরে নিন secret ফাঁস হয়ে গেছে: কেউ clone করে থাকতে পারেন, কোনো bot দেখে থাকতে পারে। History পরিষ্কারে সময় লাগে আর সব কপি মোছা যায় না (অংশ ৬)। তাই incident response-এর ক্রম:

History পরিষ্কার — git filter-repo

Git-এর নিজের documentation (git help filter-branch) পুরোনো git filter-branch-এর বদলে git filter-repo ব্যবহারের পরামর্শ দেয়। filter-repo একটি আলাদা Python tool — Git-এর সাথে আসে না, আলাদা install করতে হয় (package manager বা project-এর নির্দেশনা দেখুন)। এই পরীক্ষার কম্পিউটারে এটি নেই:

$ git filter-repo --version
git: 'filter-repo' is not a git command. See 'git --help'.

তাই নিচের command-গুলো চালানো হয়নি, শুধু documentation-অনুযায়ী উদাহরণ; চালানোর আগে নিজের সংস্করণের git filter-repo --help পড়ুন:

# 1) work on a FRESH clone (filter-repo refuses a non-fresh repo by default)
git clone https://github.com/example/bazar-app.git bazar-clean
cd bazar-clean

# 2a) remove a whole file from every commit
git filter-repo --invert-paths --path .env

# 2b) OR keep files, replace the secret text everywhere
#     replacements.txt — one rule per line; a line with no "==>"
#     is replaced by ***REMOVED***
#       FAKE_sk_test_9fQ2xLm4Rt7Vb1Nz
#       regex:FAKE_sk_test_[A-Za-z0-9]+==>REDACTED
git filter-repo --replace-text ../replacements.txt

# 3) check, then push every branch and tag (coordinate with the team first)
git log -p -S "FAKE_sk_test" --all        # expect: nothing
git remote add origin https://github.com/example/bazar-app.git   # filter-repo removes origin
git push --force --all origin
git push --force --tags origin

পুরোনো পথ: filter-branch — আর তার সতর্কবার্তা

filter-branch Git-এর সাথেই আসে, তাই কোন সমস্যার কথা Git নিজে বলে, দেখা যাক। একই repository-তে প্রতিটি commit-এর index থেকে .env সরানো হলো:

$ git filter-branch --index-filter "git rm -q --cached --ignore-unmatch .env" --prune-empty -- --all
WARNING: git-filter-branch has a glut of gotchas generating mangled history
	 rewrites.  Hit Ctrl-C before proceeding to abort, then use an
	 alternative filtering tool such as 'git filter-repo'
	 (https://github.com/newren/git-filter-repo/) instead.  See the
	 filter-branch manual page for more details; to squelch this warning,
	 set FILTER_BRANCH_SQUELCH_WARNING=1.
Proceeding with filter-branch...

Rewrite c6c1dc3… (1/4) … Rewrite b109503… (4/4) …
Ref 'refs/heads/main' was rewritten
Ref 'refs/remotes/origin/main' was rewritten
$ git log --oneline
1664c3e Lower fee to 50
d6873dc Stop tracking .env
d1af7cd Add app and settings
c6c1dc3 Add README
$ git for-each-ref --format="%(refname)"
refs/heads/main
refs/original/refs/heads/main
refs/original/refs/remotes/origin/main
refs/remotes/origin/main
$ git grep -n "PAYMENT_API_KEY" $(git rev-list --all)
1799e4e1869584595b12ccb62aa861ff7da3ffbf:.env:2:PAYMENT_API_KEY=FAKE_sk_test_9fQ2xLm4Rt7Vb1Nz
$ git cat-file -t 2113fdb
blob
$ git for-each-ref --format="delete %(refname)" refs/original/ | git update-ref --stdin
$ git reflog expire --expire=now --all
$ git gc -q --prune=now
$ git cat-file -t 2113fdb
fatal: Not a valid object name 2113fdb

filter-repo-র --replace-text আসলে কী করে, আর কেন সেটা অন্য কপিতে পৌঁছায় না — একটি ছোট মডেলে দেখুন। এখানে commit id-কে Git-এর মতো বিষয়বস্তু আর parent-এর hash দিয়ে বানানো হয়েছে (Python-এর hashlib SHA-1, প্রথম ৭ অক্ষর; আসল Git object-এর format আলাদা, তাই hash Git-এর সাথে মিলবে না):

import hashlib
# Model of what `git filter-repo --replace-text` does. The secret is FAKE.
SECRET = "FAKE_sk_test_9fQ2xLm4Rt7Vb1Nz"
history = [("Add README", "# Bazar app"),
           ("Add settings", "DB_HOST=localhost\nPAYMENT_API_KEY=" + SECRET),
           ("Stop tracking key", "DB_HOST=localhost"),
           ("Lower fee to 50", "DB_HOST=localhost\nFEE=50")]
def build(hist):
    commits, parent = [], ""
    for msg, text in hist:   # id depends on content AND parent, like Git
        cid = hashlib.sha1((parent + msg + text).encode()).hexdigest()[:7]
        commits.append({"id": cid, "msg": msg, "text": text})
        parent = cid
    return commits
def replace_text(hist, old, new="***REMOVED***"):
    return [(m, t.replace(old, new)) for m, t in hist]
server = build(history)
old_clone = [dict(c) for c in server]          # a teammate cloned earlier
server = build(replace_text(history, SECRET))  # rewrite + force push
for before, after in zip(old_clone, server):
    same = "same" if before["id"] == after["id"] else "NEW "
    print(f"{before['id']} -> {after['id']} {same} {after['msg']}")
print("server, Add settings:", server[1]["text"].splitlines()[1])
leak = [c["id"] for c in old_clone if SECRET in c["text"]]
print("old clone still has secret in:", leak)
print("ids that changed:", sum(a["id"] != b["id"] for a, b in zip(old_clone, server)))

323be1a -> 323be1a same Add README
eb89f0c -> 5fc9e36 NEW  Add settings
58b7a8c -> 5512840 NEW  Stop tracking key
d596dca -> a1afbb1 NEW  Lower fee to 50
server, Add settings: PAYMENT_API_KEY=***REMOVED***
old clone still has secret in: ['eb89f0c']
ids that changed: 3

৬ · Push-এর পরে secret কোথায় কোথায় থেকে যায়

আসল পরীক্ষায় একটি bare “server” আর rewrite-এর আগে বানানো একটি সহকর্মীর clone (oldclone) রাখা হয়েছিল। পরিষ্কার history force push করার পরে:

$ git push --force origin main
To ../server.git
 + b109503...1664c3e main -> main (forced update)
$ git -C ../server.git cat-file -t 2113fdb
blob
$ git -C ../oldclone fetch
From C:/…/t57/leak/../server
 + b109503...1664c3e main       -> origin/main  (forced update)
$ git -C ../oldclone log --oneline --all
b109503 Lower fee to 50
1664c3e Lower fee to 50
93fa95a Stop tracking .env
d6873dc Stop tracking .env
1799e4e Add app and settings
d1af7cd Add app and settings
c6c1dc3 Add README
$ git -C ../oldclone show 1799e4e:.env
DB_HOST=localhost
PAYMENT_API_KEY=FAKE_sk_test_9fQ2xLm4Rt7Vb1Nz

৭ · চাবি নিরাপদে রাখা — credential helper, token আর SSH key

পর্ব ১৪-এ দেখেছেন, HTTPS-এ token আর SSH-এ key দিয়ে remote-এ ঢুকতে হয়। এই চাবিগুলো কোথায় আর কতটা ক্ষমতা নিয়ে থাকে, সেটাই এখানে। HTTPS-এর token মনে রাখে credential helper:

Token নিজেও least privilege মেনে বানাতে হয়: শুধু দরকারি repository, শুধু দরকারি অনুমতি (পড়া, নাকি লেখাও), আর মেয়াদসহ। অনেক platform এখন repository-ভিত্তিক সূক্ষ্ম অনুমতির (fine-grained) token দেয় — নাম আর সুবিধা platform-ভেদে আলাদা।

SSH-এর দিকে কয়েকটি অভ্যাস:

• নতুন key ed25519: ssh-keygen -t ed25519 -C "you@example.com". Ed25519 ছোট, দ্রুত আর আধুনিক; খুব পুরোনো server-এর জন্য RSA লাগলে অন্তত ৩০৭২ বা ৪০৯৬ bit (বর্তমান প্রচলিত পরামর্শ)।
• Passphrase: private key ফাইলকে এনক্রিপ্ট করে; ssh-agent একবার খুলে memory-তে রাখে, তাই বারবার লিখতে হয় না।
• ~/.ssh/config: host অনুযায়ী কোন key, তা ঠিক করা যায় — যেমন কাজের আর ব্যক্তিগত account-এর আলাদা key.
• Deploy key: server বা automation-এর জন্য একটি repository-তে বাঁধা SSH key, সাধারণত শুধু পড়ার অনুমতি। ব্যক্তিগত key server-এ রাখার চেয়ে অনেক নিরাপদ, কারণ ফাঁস হলে ক্ষতি এক repository-তে সীমিত।

# ~/.ssh/config  (example; host names and paths are made up)
Host github-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

# then use:  git clone git@github-work:example/bazar-app.git

নিচের checker এই পর্বের নিয়মগুলো (কোনো আনুষ্ঠানিক মান নয়) কয়েকটি কাল্পনিক setup-এ প্রয়োগ করে:

// Credential setup checker. The RULES are this lesson's own teaching rules,
// not an official standard. Each setup is a made-up example.
function check(s) {
  const notes = [];
  if (s.helper === "store") notes.push("HIGH: 'store' keeps the token as plain text in ~/.git-credentials");
  if (/^https:\/\/[^\/@]+:[^\/@]+@/.test(s.remoteUrl)) notes.push("HIGH: token written inside the remote URL");
  if (s.helper === "cache") notes.push("info: 'cache' keeps it in memory only, for a timeout");
  if (["manager", "osxkeychain", "libsecret"].includes(s.helper)) notes.push("ok: OS-protected store");
  if (s.tokenScopes && s.tokenScopes.includes("admin")) notes.push("MEDIUM: token has admin scope; least privilege says no");
  if (s.tokenDays === null) notes.push("MEDIUM: token never expires");
  if (s.sshKey && !s.sshPassphrase) notes.push("MEDIUM: SSH private key has no passphrase");
  if (s.sshKey === "rsa-1024") notes.push("HIGH: 1024-bit RSA is too weak; use ed25519");
  return notes;
}
const setups = {
  "laptop A": { helper: "manager", remoteUrl: "https://github.com/example/bazar.git",
                tokenScopes: ["repo:read", "repo:write"], tokenDays: 90 },
  "laptop B": { helper: "store", remoteUrl: "https://rahim:FAKE_token_123@github.com/example/bazar.git",
                tokenScopes: ["admin"], tokenDays: null },
  "server C": { helper: "cache", remoteUrl: "git@github.com:example/bazar.git",
                sshKey: "ed25519", sshPassphrase: false },
  "old box D": { helper: "", remoteUrl: "git@github.com:example/bazar.git",
                 sshKey: "rsa-1024", sshPassphrase: true },
};
for (const [name, s] of Object.entries(setups)) {
  const notes = check(s);
  const worst = notes.some(n => n.startsWith("HIGH")) ? "FIX NOW" :
                notes.some(n => n.startsWith("MEDIUM")) ? "improve" : "fine";
  console.log(`${name}: ${worst}`);
  for (const n of notes) console.log("   " + n);
}

laptop A: fine
   ok: OS-protected store
laptop B: FIX NOW
   HIGH: 'store' keeps the token as plain text in ~/.git-credentials
   HIGH: token written inside the remote URL
   MEDIUM: token has admin scope; least privilege says no
   MEDIUM: token never expires
server C: improve
   info: 'cache' keeps it in memory only, for a timeout
   MEDIUM: SSH private key has no passphrase
old box D: FIX NOW
   HIGH: 1024-bit RSA is too weak; use ed25519

৮ · Git নিজেও শক্ত হচ্ছে — SHA-1, safe.directory আর খোলা .git folder

SHA-1 collision আর hardened SHA-1

Git প্রতিটি object-এর নাম দেয় তার বিষয়বস্তুর SHA-1 hash দিয়ে (পর্ব ৫২)। দুটি আলাদা বিষয়বস্তুর একই hash হলে তাকে বলে hash collision. ২০১৭ সালের ফেব্রুয়ারিতে Google আর CWI Amsterdam-এর গবেষকেরা “SHAttered” নামে প্রথম ব্যবহারিক SHA-1 collision প্রকাশ করেন — একই hash-এর দুটি আলাদা PDF. বিপুল computing লেগেছিল, তবু বোঝা গেল SHA-1-কে আর নিরাপদ ধরা যায় না।

Git-এর সাড়া দুই ধাপে। প্রথমত, Git ২.১৩ (২০১৭) থেকে default-এ “hardened SHA-1” (SHA-1DC নামের একটি library) ব্যবহার হয়, যা SHAttered-ধাঁচের collision আক্রমণের চিহ্ন hash করার সময়ই ধরতে পারে আর তখন object গ্রহণ করে না; সাধারণ data-র hash অপরিবর্তিত থাকে। দ্বিতীয়ত, দীর্ঘমেয়াদি সমাধান হিসেবে SHA-256 object format — git init --object-format=sha256 — যা কয়েক বছর ধরে ধাপে ধাপে পরিণত হচ্ছে; hosting platform আর অন্য tool-এ সমর্থন এখনো সব জায়গায় সমান নয়। বিস্তারিত পর্ব ৫২-এ। স্বাক্ষরের জন্য এর অর্থ: signed commit tree আর parent-কে hash দিয়ে ঢাকে, তাই স্বাক্ষরের ভরসা hash-এর শক্তির ওপরও নির্ভর করে।

safe.directory আর submodule-এর file protocol

Git-এর নিজের নিরাপত্তা-ত্রুটি (প্রকাশ্য ত্রুটির তালিকায় নম্বর পায়, যাকে বলে CVE) নিয়মিত সংশোধন হয়। দুটি উদাহরণ, যা আপনার দৈনন্দিন আচরণ বদলেছে:

• CVE-2022-24765 → safe.directory: ভাগ করা কম্পিউটারে অন্য কোনো ব্যবহারকারী একটি ওপরের folder-এ .git বানিয়ে রাখলে আপনার Git সেটিকে নিজের repository ভেবে তার config মানতে পারত — সেই config-এ চালানোর মতো command থাকতে পারে। Git ২.৩৫.২ (এপ্রিল ২০২২) থেকে অন্য ব্যবহারকারীর মালিকানার repository-তে Git “dubious ownership” বলে কাজ থামায়, যতক্ষণ না আপনি নিজে git config --global --add safe.directory <path> দিয়ে বিশ্বাস জানান। Error এলে সবখানে '*' বসিয়ে দেওয়া সহজ সমাধান, কিন্তু সুরক্ষাটাই তাতে বন্ধ হয়ে যায় — শুধু নির্দিষ্ট, চেনা path যোগ করুন।
• Git ২.৩৮.১ (অক্টোবর ২০২২) → protocol.file.allow: submodule-এ local file protocol default-এ আর অনুমোদিত নয় (ব্যবহারকারী নিজে সরাসরি চালালে চলে)। অচেনা repository-র submodule যেন নীরবে আপনার কম্পিউটারের অন্য repository টেনে না আনে। Submodule-এর কাজ পর্ব ১৯-এ (বড় repository).

শিক্ষা একটাই: Git হালনাগাদ রাখুন (git --version), আর release note-এর নিরাপত্তা-অংশ পড়ুন। পুরোনো টিউটোরিয়ালের “এই error এলে এই config দিন” পরামর্শ অনেক সময় একটি সুরক্ষা বন্ধ করে।

Web server-এ ভুল করে .git folder

একটি পুরোনো কিন্তু এখনো দেখা যাওয়া ভুল: website deploy করতে পুরো repository folder server-এর public folder-এ কপি, সাথে .git. তখন https://example.com/.git/… থেকে object ফাইল নামিয়ে পুরো history — পুরোনো secret-সহ — আবার জোড়া লাগানো সম্ভব হতে পারে। রক্ষার তিনটি অভ্যাস:

• Repository নয়, artifact deploy করুন: build-এর ফল (HTML, bundle, binary) কপি করুন; .git, .env, notes কখনো public folder-এ নয়। Deployment pipeline পর্ব ৫৯-এ।
• Server config-এ dot-file বন্ধ: ভুল হলেও যেন পরিবেশন না হয়।
• যাচাই: deploy-এর পরে নিজের site-এ /.git/HEAD খুলে দেখুন — 404 বা 403 আসা উচিত।

# Apache (.htaccess or vhost): answer 404 for anything under /.git
RedirectMatch 404 /\.git

# nginx (inside the server block): refuse every dot-file except .well-known
location ~ /\.(?!well-known) {
    deny all;
}

৯ · Supply chain — release-এর ওপর ভরসা গড়া

আপনার software শুধু আপনার কোড নয়: dependency, build tool, CI, release ফাইল — পুরো পথকে বলে software supply chain. Git-এর দিক থেকে এই পথে কয়েকটি তালা:

১০ · AI-এর যুগে — নিরাপত্তার প্রশ্নে AI-কে যাচাই

“Secret push করে ফেলেছি, কী করব?” — AI assistant কয়েক সেকেন্ডে উত্তর দেবে। কিন্তু এই প্রশ্নে ভুল উত্তরের দাম বেশি, আর AI-এর কিছু চেনা ভুল আছে:

AI-এর দেওয়া নিরাপত্তা-সমাধান হাতে পেলে — চেকলিস্ট

• উত্তরে key বাতিল আর নতুন key সবার আগে আছে; না থাকলে নিজে আগে সেটা করেছি
• প্রতিটি command আর option git help বা tool-এর অফিসিয়াল documentation-এ মিলিয়েছি
• Rewrite আগে একটি throwaway clone-এ চালিয়ে git log -p -S দিয়ে ফল দেখেছি
• Force push-এর আগে দলকে জানিয়েছি; পরে সবাই re-clone করেছেন
• কোনো নিরাপত্তা-সুরক্ষা (safe.directory '*', hook বাদ দেওয়া, --no-verify) বন্ধ করার পরামর্শ মানিনি
• Prompt-এ কোনো আসল token, password, private key বা ভেতরের server-এর নাম যায়নি