One way I prevent possible catastrophic fuckups is that the 'doing code work' box that runs opencode or pi or whatever, is its entirely own separate VM and desktop environment (running as a xen or kvm guest and with its own LVM logical volume as boot/root and /home disk), than the machine running llama-server itself.
replyThe harness gets the openai-compatible endpoint fed into it to talk to llama-server across the network, but the VM has no access whatsoever to my personal files, mail, backups/deep storage, fileserver, Documents folder, etc.
> security concerns
replyYeah I recently tried the coding harness that's recommended here, Pi, in a bubble wrap sandbox and was horrified to learn that it spams multiple warnings at you if you don't give it write access to its own config/extension folder... Everyone else is rawdogging it I guess.
You are horrified it needs access to its own stuff? I mean, any software that supports plugins needs access to them, no? How is that unreasonable? And with bwrap that’s an extra cli option.
replyI think the best course is a docker container or a VM, i agree with the sentiment but trying to restrict the permissions of these things is fighting an uphill battle, it’s probably best to let them reign king in a disposable and isolated environment
replyIt's okay-ish for Rust because you only need the curl|bash for Rustup, which is meant as a development environment. On production you can, for example, use APT to download it from Debian.
replyBackdoored developers are ok?
reply