Posted by bukershok 2 hours ago
* Most people do not have passwords in plain text — an SSH key protected with a passphrase is not "plain text", for instance
* Most people have encrypted home or full disk encryption
* How can we trust your crypto implementation?
* If we are talking about in-memory plain-text during use, how does this tool protect against it?
* Containerisation is a big topic when running untrusted software for exactly (but not just) this reason
* While passwords/tokens might carry a big risk depending on what you do, I find that I worry more about my local data compared to my remote data — and virtualisation or containerisation helps with that.
I don't see the point. Once your home is unlocked, every process can see the file contents
> * Most people do not have passwords in plain text — an SSH key protected with a passphrase is not "plain text", for instance
I think you'd be surprised how many SWE do actually have plain text secrets. For example, if you do everything correctly with AWS auth, you still have a plain text token in ~/.aws -- it's short lived (typically 8hrs IIRC), but it's still there
> * Most people have encrypted home or full disk encryption
Yes. But that addresses a completely different problem. One where the whole machine is lost and an attacker then has physical access to your machine. Not when the machine is already in use and you have a rogue agent or other process.
> * How can we trust your crypto implementation?
This is written in Go and Go's standard library already has crypto functions. So there wouldn't be any need for the authors to roll their own implementation. But since it's open source, you can always check the code yourself.
> * If we are talking about in-memory plain-text during use, how does this tool protect against it?
This tool doesn't advertise that feature. Which I'm guessing you already knew. macOS, like most popular operating systems, does already have kernel-level code that makes it harder for processes to read the memory of other processes that do not belong to it. It's not entirely impenetrable, but this tool I think goes far enough for most SWE's risk appetite. If the risk that you need to guard against is greater than that, then you'd be looking at VM-level isolation rather than this kind of tool.
> * Containerisation is a big topic when running untrusted software for exactly (but not just) this reason
Indeed. And while personally, I'd still recommend containerisation, that doesn't mean this kind of tool doesn't also have merit. For example containerisation can get complicated if you have several processes that might need to work against the same project.
> * While passwords/tokens might carry a big risk depending on what you do, I find that I worry more about my local data compared to my remote data — and virtualisation or containerisation helps with that.
This surprises me because even if you're not using cloud computing, your local machine is still typically just the development environment and it's your "remote" (whether that's in a DC somewhere or hosted on-prem) is where the actual data, compute and infrastructure exist.
If you a developer or just using API in your day to day you will have secretes in plaintext on your projects.
I have a small wrapper script [1] that prompts for the private key which allows me to paste it from my password manager and launches a shell with the env variables decrypted. This allows me to avoid storing any secrets while still having shell session open where I can terminate and restart a server process for example without having to re-enter the secret all the time.
[1] https://gist.github.com/ryuuseijin/0cf6ab852fbb18d6702933a24...
curl -sL https://dl.jitpass.com/jitpass/jit/releases/latest/download/jitpass_darwin_arm64.tar.gz | tar -xz jit
sudo mv jit /usr/local/bin/
The readme even says so itself:
> A bad curl | sh, a sketchy npm install, or one of the AI agents now running in your editor with your full permissions.
And then, two paragraphs down, it suggests to do just that to install…
You're still installing the program directly from github of course, instead of a source where hopefully a third party has also looked at it (like a package repository). But this is a lot better than the curl | sh pattern.
And an executable can do exactly the same as a shell script. The point is that whatever you're executing isn't verified, whether it's a shell script or a binary.
The GP said:
> This should be an ordinary app bundle to drop into /Applications
There is no difference between downloading an app bundle that you drop into /Applications, and curling a binary that you put in /usr/local/bin/
It works with 1password cli (https://www.1password.dev/cli) to access for agents/scripts, and I get a nice UI to manage them in the 1password app.
Other 1pass is a great UX. It was even greater before Electron refactor and non-subscription model.
A bit uncomfortable in leaving a secret in the history. Hence I was looking for a tool like this.
All desktop and server operating systems currently assume the user should have "full control" making a single compromise fatal for the user or even an entire organization.