Security actions

Created: 2026-05-02 Block A.1 deliverable: documentation of all manual security actions Jean must execute. Items I (assistant) cannot do automatically because they require credentials, panel access, or destructive operations needing approval.

---

Status summary

Item	Severity	Auto/Manual	Status
GOST p12 ЭЦП key in working tree	HIGH	Mixed	.gitignore updated ✓; Jean: move to encrypted vault
Notion bearer token in .mcp.json committed to git history	CRITICAL	Manual	Jean: rotate token at Notion immediately
DNS records info@oiynup.kz (DKIM + MX + SPF)	HIGH (blocks outreach)	Manual	Jean: execute via hoster.kz + Google Admin

---

Item 1 — GOST p12 ЭЦП key

Current state

File location: projects/oinap/ТОО Гринвич/GOST512_816002d4d39f9211d0b7b24e4adfe74a67939fed.p12

Good news: verified via git log --all --oneline -- "projects/oinap/ТОО Гринвич/GOST512_816002d4d39f9211d0b7b24e4adfe74a67939fed.p12" — the file is NOT in git history. Only present in working tree. No destructive history rewrite required.

Done automatically (✓)

.gitignore patterns added at root:

*.p12
*.pfx
*.crt
GOST*.p12
**/eds-key*

This prevents accidental future commits.

What Jean must do (manual)

Move the working copy to an encrypted vault. The file should not sit unencrypted on the filesystem long-term. Options ranked by recommendation:

Option A (recommended) — macOS encrypted disk image

# Create encrypted dmg (256-bit AES, Jean sets password at prompt)
hdiutil create -encryption AES-256 -size 100m -fs APFS -volname "OINAP-Vault" ~/oinap-vault.dmg

# Mount it
hdiutil attach ~/oinap-vault.dmg

# Move p12 inside
mv "/Users/jeanwwd/Desktop/jean-design/projects/oinap/ТОО Гринвич/GOST512_816002d4d39f9211d0b7b24e4adfe74a67939fed.p12" /Volumes/OINAP-Vault/

# Eject when done
hdiutil detach /Volumes/OINAP-Vault

When Jean needs to sign a document, mount the dmg, use the p12, eject.

Option B — macOS Keychain

Import p12 into Keychain.app → “login” keychain → set “Always Ask” access policy. macOS handles encryption at rest.

security import "путь к файлу.p12" -k ~/Library/Keychains/login.keychain-db -A

Option C — 1Password / Bitwarden secure file attachment

Upload p12 to vault, attach passphrase. Decrypt only when needed.

Option D (least secure but simplest) — keep in corporate/ folder, gitignored

After folder cleanup (Block A.3), move to:

projects/oinap/corporate/eds-key.p12

This sits in the working tree but .gitignore patterns above prevent commit. Risk: still unencrypted at rest, not protected if laptop stolen. Use only if Jean signs documents very frequently and Options A/B/C are too much friction.

What I (assistant) recommend

Option A (encrypted dmg) — best balance of security + workflow friction. Mount when needed, ejected by default.

---

Item 2 — Notion bearer token rotation (CRITICAL)

Current state

File: /Users/jeanwwd/Desktop/jean-design/projects/oinap/.mcp.json

Contains: Bearer ntn_B3386462753ZSNlhJFHWv8H2vaLF1WQ3H1MdsOlec7d6eg

Confirmed exposed in git history: commit ff766640 jean-design: IM.8a — move all projects into projects/ folder — this token is permanently in git log on NAS remote.

Done automatically (✓)

.gitignore updated to prevent future .mcp.json commits:

.mcp.json
projects/*/.mcp.json
**/.mcp.json

What Jean must do (manual, do this NOW)

Step 1 — Revoke exposed token

1. Open https://www.notion.so/my-integrations
2. Find the integration with token starting ntn_B3386462...
3. Click integration → Settings → Revoke token (or “Refresh secret” depending on UI)
4. Confirm revocation

After revocation, the leaked token in git history is dead — no value to attackers.

Step 2 — Issue new token

1. Same panel → “Refresh secret” generates new ntn_...
2. Copy the new token
3. Send it to me (paste in next chat) — I’ll update .mcp.json locally
4. Do NOT commit the updated .mcp.json — gitignore now prevents it

Step 3 — Optional: rewrite git history to scrub old token

Lower priority since token is dead after revocation, but for completeness:

cd /Users/jeanwwd/Desktop/jean-design

# Install git-filter-repo if not already
brew install git-filter-repo

# Scrub the old token from all history
git filter-repo --replace-text <(echo "ntn_B3386462753ZSNlhJFHWv8H2vaLF1WQ3H1MdsOlec7d6eg==>REDACTED_TOKEN")

# Force-push to NAS remote (DESTRUCTIVE — overwrites branch)
git push --force-with-lease nas main

Warning: force-push rewrites NAS branch. Other clones (CI, other agents) will need to re-clone or rebase.

Recommendation: skip Step 3 unless you have a specific reason. Revocation alone is sufficient security-wise.

Step 4 — Future: use environment variable instead of inline token

After getting new token, change .mcp.json to reference env var:

{
  "mcpServers": {
    "notion": {
      "command": "npx",
      "args": ["-y", "@notionhq/notion-mcp-server"],
      "env": {
        "OPENAPI_MCP_HEADERS": "{\"Authorization\":\"Bearer ${NOTION_TOKEN}\",\"Notion-Version\":\"2022-06-28\"}"
      }
    }
  }
}

Then put NOTION_TOKEN=ntn_... in ~/.zshrc (or .envrc if using direnv). Even if .mcp.json accidentally commits, no token leaks.

---

Item 3 — DNS records info@oiynup.kz

Current state (per partnerships/DNS_CHECKLIST.md 2026-04-07)

Record	Status	Current value
SPF	⚠️ Wrong	v=spf1 +a +mx include:_spf.ps.kz -all (no Google)
MX	⚠️ Wrong	smtp.google.com (smtp ≠ mx) + mail.oiynup.kz
DKIM	❌ Missing	No google._domainkey.oiynup.kz record
DMARC	❌ Missing	No _dmarc.oiynup.kz record

Impact: every email from info@oiynup.kz goes to spam. Outreach pipeline blocked until fixed.

What Jean must do (manual)

Per existing partnerships/DNS_CHECKLIST.md, in order:

Step 1 — Update SPF (TXT record on oiynup.kz)

Old: v=spf1 +a +mx include:_spf.ps.kz -all New: v=spf1 +a +mx include:_spf.ps.kz include:_spf.google.com -all

Edit via hoster.kz DNS panel.

Step 2 — Fix MX records (on oiynup.kz)

Remove:

• 1 smtp.google.com
• 10 mail.oiynup.kz (only if not used for separate mail server)

Add:

• 1 aspmx.l.google.com
• 5 alt1.aspmx.l.google.com
• 5 alt2.aspmx.l.google.com
• 10 alt3.aspmx.l.google.com
• 10 alt4.aspmx.l.google.com

Step 3 — Configure DKIM in Google Workspace

1. https://admin.google.com → Apps → Gmail → “Authenticate email”
2. Select domain oiynup.kz
3. Generate new DKIM record
4. Copy the resulting TXT value
5. Add to DNS as google._domainkey.oiynup.kz (TXT record)
6. Return to Google Admin → “Start authentication”

Step 4 — Add DMARC (TXT record on _dmarc.oiynup.kz)

v=DMARC1; p=none; rua=mailto:info@oiynup.kz

Start with p=none (monitor mode). After 2-4 weeks of clean reports, can tighten to p=quarantine.

Step 5 — Wait + verify

• DNS propagation: 24-48 hours
• Test with https://mail-tester.com (send test email to address provided, expect score 9-10/10)
• Verify with https://mxtoolbox.com (enter oiynup.kz)

Block on outreach until fixed

Apps Script in partnerships/apps-script/Code.gs is ready to send batch outreach but should NOT trigger until DNS confirmed clean. Jean: complete Steps 1-4 before greenlighting any batch send.

---

Sign-off checklist for Jean

• Item 1: Decide on p12 vault option (A/B/C/D), execute migration
• Item 2 Step 1-2: Revoke + issue new Notion token (URGENT — do today)
• Item 2 Step 4: Migrate to env-var pattern (after Step 1-2)
• Item 3 Step 1-4: Execute DNS changes via hoster.kz panel + Google Admin
• Item 3 Step 5: Wait propagation + verify with mail-tester.com
• Confirm in next chat session: items 1-3 status, share new Notion token (or env-var setup) so I can update local .mcp.json

---

What I (assistant) did automatically in Block A.1

• ✓ Updated root .gitignore to add *.p12, *.pfx, *.crt, GOST*.p12, **/eds-key*, .mcp.json patterns
• ✓ Verified GOST p12 NOT in git history (no destructive cleanup needed)
• ✓ Verified .mcp.json IS in git history (commit ff766640) — Jean must rotate token
• ✓ Read existing DNS_CHECKLIST.md — comprehensive, no edits needed
• ✓ Wrote this SECURITY_ACTIONS.md with full instructions

What I did NOT do (require Jean approval first):

• Did NOT run git filter-repo on .mcp.json (lower-priority since token revocation suffices)
• Did NOT touch the GOST p12 file in working tree (Jean executes vault migration)
• Did NOT modify DNS records (require Jean’s hoster.kz + Google Admin credentials)