稍微更安全的氛围编码,采用老牌黑客习惯。
Slightly safer vibecoding by adopting old hacker habits

原始链接: http://addxorrol.blogspot.com/2026/03/slightly-safer-vibecoding-by-adopting.html

这篇帖子解释了一种开发环境设置,旨在缓解现代软件安全风险,例如供应链攻击和提示注入。作者完全在租用的服务器上开发,通过SSH和密钥转发访问,并在`screen`或`tmux`会话中使用Vim和编码代理(例如Claude Code)等工具。 至关重要的是,密钥*不*存储在开发机器上。这限制了服务器被攻破的影响。为了进一步保护上游仓库免受潜在的GitHub密钥泄露,作者提倡基于分支的开发流程,并进行彻底的拉取请求审查。 这种方法最大限度地减少了对恶意软件包和代理操纵的担忧,从而可以专注于代码。有趣的是,这种“SSH进入远程机器”模式源于黑客文化,优先考虑数据安全,并且随着代理辅助编码的兴起以及对长期运行计算的需求,它正在重新获得重视。

Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 稍微安全一点的氛围 通过采用老派黑客习惯进行编码 (addxorrol.blogspot.com) 11 分,由 transpute 1小时前 | 隐藏 | 过去 | 收藏 | 1 条评论 帮助 thwarted 11 分钟前 [–] 通常是个好主意,但我不确定为什么你需要 fork 一个 git 仓库,因为本地克隆应该就足够了。但这可能只是 github 展示 fork 和克隆方式造成的术语混淆。回复 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系 搜索:
相关文章

原文

I have seen a lot of public discussion around supply-chain attacks on the Python ecosystem, prompt injection risks when using coding agents, and general worries about the security implications of "vibe coding" for the development machine.

In some of these discussions I find myself puzzled as to what problem is being solved - and it took me a while to realize that my failure to understand lies in the development setup that I tend to use.

In this blog post I'll quickly explain my development setup.

The setup is pretty simple:

  1. The actual development happens on a rented server (or a VM on that server).
  2. In order to do development, I SSH into that server with key-forwarding for my github keys enabled.
  3. I perform my development on the server by attaching to a screen or tmux session.
  4. I used to just use vim with various extensions, but with the advent of coding agents I also use claude code etc. nowadays.
  5. I avoid keeping secrets inside the development VM or on the development server.
  6. I let the agent churn away on problems for extended periods of time while I am detached from the tmux/screen.
A setup like this reduces a large number of supply-chain attacks to - at worst - compromise the development VM.

There is still a significant risk of the github key forwarding being abused to compromise the upstream main repository.

The way around this is a bit cumbersome, but not much different from what many open-source projects already do: You keep a main repository, and you *fork* a development repository from it. Then you do all your development on the dev repository, and when you're done in your development branch, you issue a cross-repository pull request.

Obviously, a human needs to go through that PR with a fine comb - but this is something you want to do for insider risk etc. anyhow, so your risk profile changes only marginally.

In a setup like this, the main secret that you'll lose in a supply chain attack are your Claude credentials. And you don't need to worry about prompt injection into your coding agent too much, and can just focus on writing code.

Interestingly, the development model of "SSH into a machine and attach to a screen session" was popularized by the hacker subculture (as in "computer break-in" subculture) since historically it was never a good idea to have data on machines you physically own. SSH'ing into a random machine in a different country that law enforcement couldn't easily get access to was a reasonable way of keeping your hands clean. I mainly switched to that development model because I almost always need long-running compute and was travelling a lot, and with agent-first development the model is seeing a bit of a resurgence.

联系我们 contact @ memedata.com