While this might be a useful tool for Mac users, it's all hackers here, so:
* 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.
For development on linux I like to use dotenvx, which lets you put encrypted secrets in an .env file and supply the private key separately.
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...
This looks like a really cool idea. But since it's a new project and has all the Claude stuff I immediately feel unsure about the solidity and reliability of a security-critical piece for software like that. I wish I could go back to my pre-LLM levels of skepticism.
Operating systems should work like Android currently does. Assuming all installed apps are potentially malicious and isolates each of them from the others and the OS. So even if an app is compromised there's not much it can do when it's installed.
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.
I am actually building the exact same thing- encrypted vaults for files or folders, encrypted with a biometric gated key in the Secure Enclave!
You can do some of this with 1Password as well btw. Looks nice!
Fnox and Nono are the ones I know that do credentials proxying. That approach seems quite better than scanning a host file system for secrets.
I would have been interested if it was for Linux
Soon, it will, yes.
I don't know about how secure this is, but I just love the UX. Scanning and process grant are great features UX-wise.
The medicine did not actually cure my terminal illness, but it surely tasted great and made me feel good about myself.
Interesting idea! How do you achieve it? Some kind of file system driver that recognises the calling process?
If only there was a Markdown file in the repo, that explains it. It could have a URL, say, https://github.com/jitpass/jit/blob/main/docs%2Fgetting-star...
Snake oil claude slop. No other words for it.
If someone or something is executing code on your machine, you have already lost. Making it _slightly harder_ for it to eventually get your passwords anyway is mostly a performative action.
__
Btw, enable "showdead" and enjoy OP actually pasting LLM output as a "defense".
- https://news.ycombinator.com/item?id=49317802
- https://news.ycombinator.com/item?id=49317819
Maybe claude can reword your claude slop for you. You can still edit those posts I guess.
[flagged]
The install procedure, for something that's supposed to be a security product:
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/
[dead]
What is wrong with it?
The pattern of piping an arbitrary script to your shell? This should be an ordinary app bundle to drop into /Applications, or be distributed as an installer.
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…
It's curl | tar, not curl | sh
But it’s not piping a script into the shell. It’s curl downloading a compressed archive and piping it to tar to decompress the program binary from the archive. Then moving the extracted binary into /usr/local/bin.
Technically this one is piping it to tar? But I agree with the sentiment.
It's not piped to a shell, but to the tar program with specific parameters to directly unpack the tar.
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.
You're not downloading from github, but from dl.jitpass.com.
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.