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.
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 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.
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.
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.
You can do some of this with 1Password as well btw. Looks nice!
I don't know about how secure this is, but I just love the UX. Scanning and process grant are great features UX-wise.
I would have been interested if it was for Linux
Soon, it will, yes.
I am actually building the exact same thing- encrypted vaults for files or folders, encrypted with a biometric gated key in the Secure Enclave!
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...
The install procedure, for something that's supposed to be a security product:
What could possibly go wrong?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 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.
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 curl | tar, not curl | sh