Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slightly safer vibecoding by adopting old hacker habits

addxorrol.blogspot.com

Post reply on HN
Print view View original

101–110 of 110 posts

Re: Slightly safer vibecoding by adopting old hacker habits

#101

Post by faangguyindia »

semanticc wrote: post #99
faangguyindia wrote: post #86

Earlier quoted context omitted.

I used to use sealtbelts for sandbox, i found it consumes way more tokens when sandboxed. Now, i run YOLO and haven't had any issue and my subscription lasts much longer with less token consumption!

How/why did it consume more tokens?

Well, thing is I ask it doesn't things where sandbox fails.

And then it has to bypass sandbox to run those command with elevated permission.

This double tripe boosts token usage.

I don't think average developer workflow can be really limited to a workspace. You'll need commands which touch your system or require more privilege

Re: Slightly safer vibecoding by adopting old hacker habits

#102

Post by amluto »

Borealid wrote: post #43

I don't understand why I keep seeing posts like this, but nobody appears to know that DevContainers exist. In a Jetbrains IDE, for example, you check a devcontainer.json file into your repository. This file describes how to build a Docker image (or points to a Dockerfile you already have). When you open up a project, the IDE builds the Docker image, automatically installs a language-server backend into it, and launch…

Keep in mind that VSCode’s own security story is beyond poor. Even if the container runtime perfectly contains the container, VSCode itself is a hole you could drive a truck through.

Re: Slightly safer vibecoding by adopting old hacker habits

#103

Post by indigodaddy »

petcat wrote: post #88
DaedalusII wrote: post #87

Earlier quoted context omitted.

yes you right, i assume you using claude code which can in fact accidentally run the wrong command https://www.reddit.com/r/ClaudeAI/comments/1n1moqy/how_did_c... https://www.reddit.com/r/ClaudeCode/comments/1sa3fx8/claude_... https://old.reddit.com/r/ClaudeAI/comments/1jfidvb/claude_tr...

My Claude runs as a limited user account, which I invoke using sudo. Claude can run whatever commands it wants and the only harm it can do is nuke its own home directory. That's the whole point.

They weren't getting that sudo was just your mechanism for changing user.

Re: Slightly safer vibecoding by adopting old hacker habits

#104

Post by arcanemachiner »

simoncion wrote: post #96
arcanemachiner wrote: post #58

Earlier quoted context omitted.

Every goddamn time with this type of dogshit advice. Perfect is the enemy of good. Don't just rawdog a coding agent because a perfectly viable solution (containers) takes an hour or two of work to set up. There's a world of difference between "it can scan your network" and "I just uploaded my private SSH keys to the cloud".

> Don't just rawdog a coding agent because a perfectly viable solution (containers) takes an hour or two of work to set up. Setting up a separate unprivileged Linux user account takes all of like a minute. Assuming that the $HOME for your daily-driver account isn't world-readable, [0] that gets you the majority of the isolation that containerization provides and doesn't expose you to any bugs in the containerization…

See, I like this. "Create a new user account" is much better advice than "don't use a container".

My problem with the latter advice is that I know for a fact that people will read it, then continue to use absolutely no protection whasoever.

I have also wanted to use a simple file permission system, but I started with a container and I can't be troubled to switch yet.

Re: Slightly safer vibecoding by adopting old hacker habits

#105

Post by arcanemachiner »

xnorswap wrote: post #71
arcanemachiner wrote: post #56

Earlier quoted context omitted.

The main Claude Code GitHub repo even has a Devcontainer config: https://github.com/anthropics/claude-code It's a great starting point, and can be customized as needed. With the devcontainer CLI, you can even use it from a terminal, no GUI/IDE required.

Is there a guide on getting it working with a devcontainer on the command line?

Yes, I summarized the process in another comment recently:

https://news.ycombinator.com/item?id=47546014

That should be enough to get you going. It can be customized to your heart's content.

Re: Slightly safer vibecoding by adopting old hacker habits

#107

Post by Havoc »

codemog wrote: post #14

I would guess OpenAI Codex and Claude Code are well into the millions subscriber range at this point. I would venture to guess the majority of them run in yolo mode. I have only seen a few horror stories on reddit. The same way any time you drive a car you can crash and die (many times through no fault of your own). All that said, no way in hell I’m giving either access to production databases or environments.

Think it’s still wise to containerize it somehow just so that it can’t nuke anything.

Being worried about escape from isolation etc in a person dev context seems like overkill though

Re: Slightly safer vibecoding by adopting old hacker habits

#108

Post by Havoc »

parliament32 wrote: post #100

Good checklist, but > The actual development happens on a rented server Why not Hyper-V or libvirt/KVM? VM escapes aren't a thing in real life (or VMs from hyperscalers wouldn't exist), so why deal with additional cost, latency, and third-party trust when you could just run it yourself?

Or even a container. Unless you’re a security researcher the average dev isn’t likely to encounter anything requiring anti escape anything at all

Re: Slightly safer vibecoding by adopting old hacker habits

#109

Post by lsaferite »

I've been using unix systems in one way or another for the last 30+ years. I only last week figured out I could use authorized_keys with dedicated commands per key as a way to transparently ssh directly into a container on a remote host.

That ability to transparently start a container and connect it to the SSH pipr is useful for isolation methods for coding agents involving containers and I imagine it would work equally well for things like Firecracker VMs. It's made my experiment working with an "immutable OS" (Universal Blue based) much more ergonomic. Also, it's the only way I've found to let Zed run remotely inside a container without having the container run a ssh server.

Re: Slightly safer vibecoding by adopting old hacker habits

#110

Post by simoncion »

arcanemachiner wrote: post #104
simoncion wrote: post #96

Earlier quoted context omitted.

> Don't just rawdog a coding agent because a perfectly viable solution (containers) takes an hour or two of work to set up. Setting up a separate unprivileged Linux user account takes all of like a minute. Assuming that the $HOME for your daily-driver account isn't world-readable, [0] that gets you the majority of the isolation that containerization provides and doesn't expose you to any bugs in the containerization…

See, I like this. "Create a new user account" is much better advice than "don't use a container". My problem with the latter advice is that I know for a fact that people will read it, then continue to use absolutely no protection whasoever. I have also wanted to use a simple file permission system, but I started with a container and I can't be troubled to switch yet.

> "Create a new user account" is much better advice than "don't use a container".

That wasn't exactly what PunchyHamster was saying. PH was saying that putting an untrusted workload in a container doesn't prevent it from scanning (and attacking) your network... so your IP network security is just as bad when that untrusted workload is containerized as when it's not. Containers/sandboxes can provide filesystem segmentation (except when they don't! [0]), but the way they're typically used, they provide zero network segmentation.

I mention in my comment here [1] that it's useful for whatever isolation mechanism you use (even if it's "just" 'a separate minimally-privileged user') to ensure that programs its spawns are on separate VLANs that your router prevents from talking to anywhere other than the Internet.

[0] https://github.com/flatpak/flatpak/security/advisories/GHSA-...>

[1] https://news.ycombinator.com/item?id=47690425>

Post reply on HN