What’s actually in there

A rolling mix:

• My own tool releases — short Russian-language announcements for projects I open-source. The polished version usually shows up here on the blog with the architecture and security posture spelled out.
• AI / agents news — Claude Code, Cursor Automations, LangChain Deep Agents, the latest local-model drops (Qwen, Gemini, Llama). Mostly focused on agentic infrastructure rather than chat-assistant hype.
• Security tooling — Bug Bounty kits, OSINT, hardware hacks (RaspyJack et al.), occasional CVE writeups.
• Self-hosting & open source — Rust CLI tools, infra utilities, bookmarks for living a little less inside big-tech defaults.
• Off-topic detours — book reviews, weird internet finds, things that genuinely cramp my brain. The channel name is a literal description.

It’s Russian by default — most of my readers are Russian-speaking infra and security folks — but tools and links work for everyone. If you read English-only, the GitHub repos linked from each post are usually self-explanatory.

Who it’s for

• People who want a pre-blog feed of what I’m currently building
• Engineers who treat their Telegram saved-messages folder as a second brain and need raw material for it
• Anyone who liked the security-audit / telegram-search / unix-pass-mcp posts and wants the next one before I get around to writing it up

Subscribe

t.me/mind_cramp →

Broadcast-only, no comments, no paywalls. Unsubscribe is one tap and I won’t take it personally.

The Problem

You want your AI assistant to:

• Pull a credential into a browser MCP for a signup flow
• Generate a password for a new account and store it back
• Compute a TOTP code on demand
• Audit which entries exist without decrypting them

What you don’t want is the model deciding to overwrite half your store because a poisoned tool result told it to.

How It’s Gated

The server exposes 24 tools across four capability tiers, each with its own env flag:

1. Read-only — always available. store_info, list, find, show, show_field, show_metadata, grep, otp, otp_uri, unlock_agent. The expensive ones (grep decrypts the whole store) require explicit confirmation.
2. Writes — PASS_MCP_ALLOW_WRITES=1. insert, set_field, generate, mv, cp, and friends. Passwords go in via stdin only — never argv — so they don’t leak into process listings.
3. Git — git_status and git_log always; git_pull / git_push need PASS_MCP_ALLOW_NETWORK=1. Pulls are --ff-only. Pushes are never --force.
4. Destructive — PASS_MCP_ALLOW_DESTRUCTIVE=1. init and reencrypt, which re-encrypt the store to a new recipient set. There is no undo.

Scope it further with PASS_MCP_ALLOWED_PATHS="work/*,personal/notes/*" and the agent literally cannot reach your banking entries — the allowlist is honoured by grep and unlock_agent too, so there are no scope escapes.

Security Posture

• No shell. Every pass invocation goes through one chokepoint using subprocess.run with shell=False and an arg list. Audited by a ruff S404 allowlist on a single file.
• Strict input validation. Pass-names match a tight regex; no .., no leading -, no control chars.
• Stderr sanitization. Anything between -----BEGIN/-----END markers is stripped before being raised back to the caller.
• Sensitive output flagged. show, generate, otp, and grep carry meta.sensitive = true so MCP hosts can refuse to log or cache them.
• Append-only audit log. Records pass-names only — never values, never grep patterns.
• Strict startup. Refuses to start if PASSWORD_STORE_UMASK is weaker than 077 or the store directory is world-readable.

The one real wart is pinentry — the MCP server can’t pop a passphrase prompt itself, since gpg would hang on stdin. So you either configure a GUI pinentry in ~/.gnupg/gpg-agent.conf, pre-warm the agent in a real terminal, or call the unlock_agent tool to bounce the prompt through zenity/kdialog. Either way, the LLM never sees the passphrase.

Honest Disclaimer

The whole point of this server is to grant an LLM access to your secrets. The capability gates, path allowlist, and audit log reduce the blast radius of mistakes and prompt injection — they don’t make it safe to point an unsupervised agent at a production credential store. With writes and network on, an agent that’s been prompt-injected by a hostile webpage in a sibling browser MCP can absolutely overwrite or exfiltrate credentials within scope.

I run mine read-only against a scoped subfolder, and only flip writes on when I’m actively running an agent through a signup flow.

Give It a Try

346 unit tests, 45 real-GPG integration tests, Python 3.11 / 3.12 / 3.13 in CI, MIT-licensed: GitHub – Neanderthal/unix-pass-mcp

If you’re already running an agent loop that combines a browser MCP with shell access, this is the bridge that lets you stop pasting passwords into chat.

The Obvious Approach Is Wrong

The first thing that comes to mind is: just scan the internet. Connect to everything, see what responds.

There are problems with this. One is scale — 2^32 IPv4 addresses. Even at 1000 connections per second (which would get you banned instantly), you’d need months. Another is that uniform scanning tells you nothing about structure. You get a flat set of reachable IPs, but no insight into why those and not others.

The bigger problem, though, is that whitelists aren’t always IP-based. If the filter looks at SNI (the hostname in the TLS handshake), then the same IP might work for one domain and fail for another. Scanning IPs would give you garbage. You’d be reconstructing a fantasy of what the filter looks like instead of what it actually is.

So the first thing you need to do is figure out what kind of filter you’re dealing with.

Phase Zero: Diagnostics

I ended up building a tool that does this in two phases. Phase zero is just diagnostics — ~5 minutes, ~5 MB of traffic, and you get a picture of the filter’s shape.

The idea is simple: run a few controlled experiments that isolate different filtering behaviors from each other.

• Connect to IPs that should always be reachable (1.1.1.1, 8.8.8.8, etc.). If these fail, something is fundamentally broken.
• Resolve domains that you suspect are blocked via a public DNS, then probe those IPs. This isolates DNS from TCP.
• Send TLS handshakes to the same IP with different SNI values. If some succeed and others fail, you’re looking at SNI filtering.
• Resolve the same set of domains against your carrier’s DNS and several public resolvers. Look for discrepancies.
• Run traceroutes to allowed and blocked targets. Count hops to find where the drop happens.

After running through this checklist, you know: is this an IP filter? SNI? DNS manipulation? A mix? Where exactly in the network does the filtering happen? How confident are you in each of these conclusions?

This seems like overhead. Why not just start scanning? Because the scanning strategy depends entirely on the answer. If it’s SNI-based, IP reconstruction is a waste of time. If it’s DNS poisoning, TCP probes won’t reveal anything. Five minutes of diagnostics saves you hours of scanning the wrong thing.

Phase One: Reconstruction

Once you know what you’re dealing with, you can actually reconstruct the whitelist.

The Details Matter

A few things I learned the hard way:

What You Actually Get

After a few hours (or a full day for a thorough scan), you have a report with four sections:

• Filter model: What kind of filter, where it sits in the network, how confident you are.
• Reconstructed whitelist: CIDRs, SNIs, or a DNS map (shape depends on filter type).
• Provider breakdown: Which cloud footprints are covered. Useful context.
• Concrete examples: 10 domains that work, 10 that don’t. Grounds the abstract analysis.

This isn’t perfect. Anycast services complicate IP reconstruction (you’re probing the local edge, not the whole advertised range). Some filters combine multiple techniques. But you get a picture that’s good enough to make decisions.

Why Do This?

There are practical reasons. Maybe you’re deciding whether to pay for a VPN. Maybe you’re planning a project that needs specific services. Maybe you just want to document what your carrier is actually doing.

But there’s also something satisfying about reverse-engineering a system that’s designed to be opaque. You take a black box, poke it systematically, and gradually form a model of what’s inside. It’s the same impulse that drives any kind of debugging or security research — wanting to understand the hidden mechanisms.

The Bigger Picture

Whitelists are becoming more common. Mobile carriers in some markets enforce them by default. Corporate networks use them. Schools. Public Wi-Fi. Sometimes they’re documented, often they’re not.

The tools to audit them are also getting better. Not just for evasion, but for transparency. If a network operator can decide what you’re allowed to access, it matters that you can audit that decision. Even if you don’t have direct access to their configuration.

I’m not saying this is a perfect solution. It has limitations. It’s not a substitute for proper documentation or transparency policies. But when nobody will tell you what’s blocked, this is how you find out.

Installation

git clone git@github.com:Neanderthal/whitelist-probe.git
cd whitelist-probe
uv sync

wlp auto
cat reports/latest/whitelist-report.md

Or a cheap first pass:

wlp --quick auto

Repository

Neanderthal/whitelist-probe

This is what happens when your internet breaks and nobody will tell you why. You figure it out yourself.

The Problem

Traditional UTM links in QR codes tell you which campaign was scanned, but not where. While some commercial services offer geolocation tracking, they often involve monthly fees, data exfiltration, or clunky UIs. I wanted something I could host on a $5 VPS that saves data directly to a format my clients already understand: Excel.

How it Works

The flow is designed to be as frictionless as possible:

1. QR Scan: The reader scans a custom QR code from a newspaper or flyer.
2. The "Lobby" Page: They hit a lightweight FastAPI endpoint. A simple "Redirecting…" page with a spinner appears.
3. Permission: The browser asks the reader: "geo.yourdomain.com wants to use your current location."
4. Capture:
   • If Allowed: GPS coordinates are sent via POST to the backend and appended to an .xlsx file.
   • If Denied (or timeout): The script proceeds regardless.
5. Redirect: The reader is instantly redirected to the final promotion or website.

Under the Hood

The project is built for reliability and ease of deployment:

• FastAPI Backend: Handles incoming telemetry and serves the JS-driven redirection page.
• Excel Storage: Uses openpyxl with thread-safe locks to write data. No database (PostgreSQL/Redis) is required, keeping the footprint tiny.
• Ansible Deployment: I’ve included a playbook that handles the entire server setup — from installing Docker and Nginx to configuring Let’s Encrypt for HTTPS (crucial, as browsers block geolocation over non-secure connections).
• QR Generator: A built-in Python script that takes a campaigns.yaml file and generates high-resolution, print-ready QR codes for each campaign.

Why Excel?

While a database would be "cleaner" for developers, this tool is meant to be used. Marketing teams and clients don’t want to query a SQL database; they want to open a file. By saving each campaign to its own .xlsx file, I can just provide an API endpoint to download the raw data directly.

Deployment in One Command

If you have a Linux server and a domain, you can get this running in minutes:

# Set your variables in vars.yml
cd ansible
ansible-playbook -i inventory.ini deploy.yml

Give it a try

The source code is open and available on GitHub:
GitHub - Neanderthal/users_geoposition

If you’re running print ads and want to see a heatmap of where your audience actually is, this tool is for you.

The Goal

The objective was simple: allow an LLM (like Claude) to answer questions like “What was that database migration snippet Sergey sent last Tuesday?” or “Summarize the recent discussion in the project-alpha group.”

How it Works

The project implements the Model Context Protocol, acting as a bridge between the Telegram API and an AI client.

1. Authentication: It uses a one-time session creation script (create_session.py) to generate a secure Telethon session.
2. MCP Tools: It exposes several tools to the AI:
   • search_messages: Keyword search within a specific chat.
   • search_global: Search across all your dialogs.
   • get_message_context: Retrieve the “surrounding” messages of a specific post to give the AI context.
   • get_chat_history: Fetch recent messages with pagination.
3. Read-Only Safety: By design, this server does not include sending capabilities. It’s meant for context retrieval, ensuring your agent won’t accidentally post on your behalf while “thinking.”

Key Features

• Deep Context: Unlike basic keyword search, the get_message_context tool allows the AI to see what happened before and after a hit, making summaries much more accurate.
• Media Filtering: Support for global searches filtered by type (photos, documents, links, etc.).
• Lazy Loading: The Telegram client connects only when a tool is first invoked, making the MCP initialization instant.

Why MCP?

The Model Context Protocol is becoming the standard for connecting local data to LLMs. By packaging this as an MCP server, it works out-of-the-box with Claude Desktop, Claude Code, and any other compatible IDE or CLI tool.

Under the Hood

The stack is Python 3.12, using FastMCP for the server logic and Telethon for the Telegram MTProto interaction. It’s lightweight enough to run in the background of your workstation.

Give it a try

The source code and setup guide are available on GitHub:
GitHub - Neanderthal/telegram-search

If you want your AI assistant to actually know what’s going on in your primary communication channel, this is the bridge you need.

Goals

The main objectives behind security-audit are: - Comprehensive Coverage: Go beyond basic OS-level package audits by checking Python (pip), Rust (cargo), and Node (npm) environments. - Local Isolation: Run locally without relying on heavy cloud scanners that exfiltrate data. - Easy Integration: Use standard Linux tools (bash, Python) so it can be dropped into any Unix-like dev machine (like Ubuntu or Manjaro) without huge dependency chains. - Actionable Output: Clearly distinguish between critical CVEs (CVSS >= 7.0) and minor warnings, allowing the developer to quickly patch what matters.

The Process

The tool executes a modular checklist, hitting several critical security vectors:

1. OS Vulnerabilities: Uses local package managers and external sources (like OSV.dev) to check for outdated and vulnerable system packages.
2. Environment Scanning: Deep dives into your language-specific ecosystems. It checks pip packages via pip-audit, Rust crates via cargo-audit, and Node.js packages via npm audit.
3. Permissions & Secrets: Scans for world-writable sensitive files, unprotected private keys (~/.ssh/), and accidentally committed secrets.
4. Firewall & Network: Validates that ufw or iptables rules are active, checks for unnecessarily open ports, and flags insecure SSH daemon configurations.
5. Report Generation: Aggregates findings into an actionable summary, highlighting Critical and High issues.

Pros & Cons

Comparison

How does security-audit stack up against other tools?

• vs. Trivy: Trivy is fantastic, but it’s heavily optimized for container images and CI pipelines. security-audit is designed specifically for the host workstation, bridging the gap between OS config and local dev dependencies.
• vs. Lynis: Lynis is the gold standard for POSIX host auditing. However, it focuses heavily on system compliance (file permissions, kernel hardening). security-audit incorporates developer-specific checks (like scanning local virtual environments and cargo registries) which Lynis doesn’t do out of the box.
• vs. Snyk/Dependabot: These are great for source code repositories and CI/CD integrations. security-audit looks at what is actually installed and running on your local machine, not just what’s in a requirements.txt file.

Give it a try

You can check out the source code, contribute, or grab the latest release on GitHub:
GitHub - Neanderthal/security-audit

If you are a developer looking to lock down your local Linux environment against supply-chain attacks and basic misconfigurations, this tool might save you a significant headache.

Step-by-Step Guide to Running Local Models

1. Prepare the Environment: Ensure that you have a suitable environment for running Docker containers, with Docker installed and configured correctly on your system. Additionally, if you plan to use machine learning models, make sure your machine has the necessary GPU support and that Docker can access these resources.

2. Clone the Model with Git LFS: Before you can run the model, you need to have it on your local machine. Use Git Large File Storage (LFS) to handle large files typically associated with models. Here’s how you can clone an example model, such as flan-t5-xl from Hugging Face:

   cd /data
   git clone https://huggingface.co/google/flan-t5-xl

   Ensure that you have git lfs installed before you clone the repository, as this will allow you to pull large model files correctly.

3. Run the Docker Container: With the model downloaded, you can now run the Docker container. The following command demonstrates how to set up the Docker container to use the GPU, map the ports, and link the local model directory:

   docker run --rm --gpus all -p 8080:80 -v /data:/data --pull always ghcr.io/huggingface/text-generation-inference:latest --model-id /data/flan-t5-xl

   • --rm: Cleans up the container after you stop it.
   • --gpus all: Ensures that Docker can use all available GPUs.
   • -p 8080:80: Maps port 80 in the container to port 8080 on your host, allowing you to access the service via localhost:8080.
   • -v /data:/data: Mounts the local /data directory to /data in the container, providing access to the model data.
   • --pull always: Ensures that Docker pulls the latest version of the image.
   • --model-id /data/flan-t5-xl: Points to the model you downloaded, instructing the container to load this specific model.

Conclusion

Running local models doesn’t have to be a headache. By following the steps above, you can quickly get your LLM model running locally using the TGI Docker container. This approach is streamlined, efficient, and ensures that you are always running your model with the latest and most secure container settings. Whether you’re developing new applications or just experimenting with different models, this method provides a reliable and straightforward solution.

Step 1: Save the Docker Image

First, save the Docker image to a tar file:

docker save ghcr.io/huggingface/text-generation-inference:2.0 -o tgi.tar

This command converts the Docker image into a tar archive, tgi.tar.

Step 2: Transfer the Image

Next, use scp to transfer the tar file to the target server:

scp tgi.tar <username>@<server>:/data/projects/inference_test

Ensure you replace istomin with your username and modify the server address and directory as necessary.

Step 3: Load the Image on the Destination Server

After transferring, log into the destination server and load the image from the tar file:

docker load -i tgi.tar

Step 4: Verify the Image

Confirm the image is loaded correctly:

docker images

Check for the text-generation-inference image in the output list.

Conclusion

This method provides an efficient way to move Docker images across servers without needing a Docker registry, perfect for environments with restricted internet access.

This condensed version focuses on the essential steps, ensuring clarity and brevity for quick reference.

General Principles:

1. Prefer EAFP over LBYL:
   • Use try/except (EAFP) instead of pre-checking conditions (LBYL) when errors are expected.
     
   • EAFP is more robust because it avoids race conditions and handles errors directly.
2. Avoid Catching All Exceptions:
   • Catching Exception or bare except: hides bugs. Only catch specific exceptions you can handle.
     
   • The only exception is at the top level (e.g., CLI/GUI/web apps), where you log the error and exit gracefully.
3. Let Errors Bubble Up When Appropriate:
   • If your function can’t recover from an error, don’t catch it. Let higher-level code handle it.
     
   • This keeps code clean and separates concerns (e.g., database errors should be handled by the framework, not individual routes).

Error Handling Strategies:

Best Practices:

4. Use Specific Exception Classes:
   • Catch only the exceptions you expect (e.g., OSError for file ops, SQLAlchemyError for DB issues).
5. Logging Over Silencing:
   • If you catch an error, log it with logger.exception() to include the stack trace.
6. Separate Error Handling Logic:
   • Move error recovery to higher layers (e.g., framework-level handlers) to avoid repetitive code.
7. Development vs. Production:
   • In development, let crashes show stack traces for debugging.
     
   • In production, catch all exceptions at the top level and log them (e.g., return a 500 error in web apps).
8. Avoid Redundant Checks:
   • Don’t pre-check conditions (LBYL) if the operation itself raises clear exceptions (EAFP).

Examples of Anti-Patterns to Avoid:

• Catching Exception in mid-level functions.
  
• Logging an error but not re-raising it when recovery isn’t possible.
  
• Repeating error-handling logic across multiple functions (e.g., rolling back DB sessions in every route).

By following these tips, you’ll write cleaner, more maintainable code that handles errors effectively while avoiding common pitfalls.