Inside ZCode: Silently uploading your Git history to the cloud
Thread
Unofficial Hacker News client; not affiliated with Y Combinator.
Inside ZCode: Silently uploading your Git history to the cloud
Unofficial Hacker News client; not affiliated with Y Combinator.
philbo · · focus · HN ↗
I'm sure there's a perfectly reasonable explanation for it, which has nothing at all to do with exfiltration of secrets, but it does amuse me when it happens. I imagine the labs have access to lots of secrets that various actors would like to get their hands on...
(shameless plug for my own harness, which is open source and doesn't have a backend to send any data to: <a href="https://www.opairdev.org/" rel="nofollow">https://www.opairdev.org/ )
alightsoul · · focus · HN ↗
belowavgiq · · focus · HN ↗
It's good that the objective is to have the model work as a helper, but that's what everyone can already do with CC or Codex as long as you don't ask to "write this entire x thing". It's also what a billion other, often vibecoded, harnesses claim they can do.
Why should I use yours, which also forces me off my existing subscriptions? Maybe it's (mostly) handwritten, so it's mindful efficient code instead of slop, and each adjustment was made through trial and error with current models? maybe it IS slop but at least you have a unique feature? and so on and so forth.
sva_ · · focus · HN ↗
Haven't used it after that.
princevegeta89 · · focus · HN ↗
however...when it is debugging problems or responding to questions about the code, it will just say it read my env file and found xxx environment variables as a verification step, or sometimes it will even mention that I need to uncomment some environment variables in the env file, which makes the whole deal about security feel iffy giffy....
thehamkercat · · focus · HN ↗
Encrypt: sops encrypt --input-type dotenv --output-type dotenv .env > secrets.enc.env
then rm .env
You can then run your script/dev with: sops exec-env secrets.enc.env 'docker xxxx' (it will ask you for your password, or touch-id to decrypt the secrets)
I like this because this way the .env doesn't sit in the directory at all, and is only passed to your dev environment and stays in it while it's running
Decrypt back to a file (if you ever want that): sops decrypt secrets.enc.env > .env
---
Well ofc, any agent can do docker inspect to get all those env vars, but atleast reading the dotfiles won't do anything
you can also edit the file with: sops --input-type dotenv --output-type dotenv secrets.enc.env
booi · · focus · HN ↗
Ferret7446 · · focus · HN ↗
graemep · · focus · HN ↗
In development you should not be using the real production values.
[deleted] · · focus · HN ↗
[deleted]