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.
I'm not the author but i can probably answer some of these:
> * 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 bypassable, 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 of hosted on-prem) is where the actual data, compute and infrastructure exist.
* Dealing with encrypted files is easy, and more versatile than a generic wrapper. E.g. to load a secret environment: `eval $(age -d -i secrets.env.age)`. With the added bonus that it only relies on a trusted tool, age.
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.
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.
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 verbatim as a "defense".
Maybe claude can reword your claude slop for you. You can still edit those posts I guess.
__
bukershok 2 minutes ago [dead] | parent | context | flag | vouch | favorite | on: Show HN: Laptop is the last place your secrets are...
Worth separating two things here.
That's curl | tar, not curl | sh, as a few people noted. But the real answer is: don't use it. The recommended install is brew install jitpass/tap/jitpass.
Releases are Developer ID signed and notarized by Apple. Homebrew quarantines its download and Gatekeeper checks it against the notarization ticket before it runs. jit doctor reports the Team ID it verified, so you can check rather than take my word for it. jit upgrade refuses to install anything whose signature and checksum don't both verify, with no override flag.
The tarball line is there for people without Homebrew, and it is the weaker path precisely because curl sets no quarantine bit, so Gatekeeper never consults the ticket. Point taken: leading with it in the README undercuts the argument on the same page. I'll flip the order.
__
Sorry if this violates the "no dunking" rule or whatever, but this cancer needs to be eradicated.
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.
How funny it may sound, but I was recently researching around for these kinds of tools for the same exact purposes.
Where I got stuck was at the Secure Enclave storing biometric-crypted payloads in the keychain, but couldn’t get it to work without Apple Developer subscription for code signing, otherwise these features wouldn’t work. And nobody with an Apple Developer subscription wants to sign someone else’s code, obviously. I really wonder why Apple itself, or any other reputable company, didn’t publish an utility like this already - it’s also a trust issue, when you run code like this.
The issue is that /usr/sbin/security invocations can be obscured to read from keychain, but require password typing every time, which is annoying. And lazy people can just hit “trust” by mistake. And then it’s just another clear text, but more annoying to reach.
Even though, it may be possible to show a touchID prompt in two other scenarios:
- encrypting payload with a key stored in the enclave - then it becomes closer to SOPS approach. Age plugin for sops also supports using private keys on yubikey, by the way. But SOPS UX feels clunky.
- just calling the APIs to show touchID as part of the application logic, like all modern password managers do. But then you really have to trust the password manager or the tool that does it, because touchID doesn’t equal security in this case.
Some password managers support CLI, SDK, and Terraform providers for working with their secrets, but that requires an IPC enabled, potentially increasing the risk for the other secrets stored in the same password manager.
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 read the readme in full, I think that's an appropriate level of effort. Your link also still doesn't answer it, though it hints: 'A migrated .env is a live mount (a named pipe), not a plain file'. So is that a file system driver, or...?
Even https://github.com/jitpass/jit/blob/main/docs/getting-starte... says it's a local encrypted store - and that's repeated many times across the docs Claude-style - but it doesn't explain the mechanism whereby reading a file gets the results from that store.
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.
I'm not the author but i can probably answer some of these:
> * 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 bypassable, 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 of hosted on-prem) is where the actual data, compute and infrastructure exist.
* Dealing with encrypted files is easy, and more versatile than a generic wrapper. E.g. to load a secret environment: `eval $(age -d -i secrets.env.age)`. With the added bonus that it only relies on a trusted tool, age.
> Most people have encrypted home or full disk encryption
I don't see the point. Once your home is unlocked, every process can see the file contents
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...
I've moved my secrets to 1Password Environments (https://www.1password.dev/environments), which works really well for everyday use.
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.
But the IPC is process-wide, not vault-dependent. And requires touch approval on every access, without “trust this process for X minutes” possibility.
Other 1pass is a great UX. It was even greater before Electron refactor and non-subscription model.
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.
Just a note, it’s on a Polyform Perimeter license.
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 verbatim 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.
__
bukershok 2 minutes ago [dead] | parent | context | flag | vouch | favorite | on: Show HN: Laptop is the last place your secrets are...
Worth separating two things here.
That's curl | tar, not curl | sh, as a few people noted. But the real answer is: don't use it. The recommended install is brew install jitpass/tap/jitpass.
Releases are Developer ID signed and notarized by Apple. Homebrew quarantines its download and Gatekeeper checks it against the notarization ticket before it runs. jit doctor reports the Team ID it verified, so you can check rather than take my word for it. jit upgrade refuses to install anything whose signature and checksum don't both verify, with no override flag.
The tarball line is there for people without Homebrew, and it is the weaker path precisely because curl sets no quarantine bit, so Gatekeeper never consults the ticket. Point taken: leading with it in the README undercuts the argument on the same page. I'll flip the order.
__
Sorry if this violates the "no dunking" rule or whatever, but this cancer needs to be eradicated.
The install procedure, for something that's supposed to be a security product:
What could possibly go wrong?I agree that `curl | tar && mv` is not safer than `curl | sh`.
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.
> 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/
The difference is you have the executable for examination (at least a quick virus scan) before you run it. Certanly not perfect, but what is?
You can still do that with their install instructions ;)
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
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.
How funny it may sound, but I was recently researching around for these kinds of tools for the same exact purposes.
Where I got stuck was at the Secure Enclave storing biometric-crypted payloads in the keychain, but couldn’t get it to work without Apple Developer subscription for code signing, otherwise these features wouldn’t work. And nobody with an Apple Developer subscription wants to sign someone else’s code, obviously. I really wonder why Apple itself, or any other reputable company, didn’t publish an utility like this already - it’s also a trust issue, when you run code like this.
The issue is that /usr/sbin/security invocations can be obscured to read from keychain, but require password typing every time, which is annoying. And lazy people can just hit “trust” by mistake. And then it’s just another clear text, but more annoying to reach.
Even though, it may be possible to show a touchID prompt in two other scenarios: - encrypting payload with a key stored in the enclave - then it becomes closer to SOPS approach. Age plugin for sops also supports using private keys on yubikey, by the way. But SOPS UX feels clunky. - just calling the APIs to show touchID as part of the application logic, like all modern password managers do. But then you really have to trust the password manager or the tool that does it, because touchID doesn’t equal security in this case.
Some password managers support CLI, SDK, and Terraform providers for working with their secrets, but that requires an IPC enabled, potentially increasing the risk for the other secrets stored in the same password manager.
Oh well, tough choices everywhere.
You can do some of this with 1Password as well btw. Looks nice!
on Linux use systemd-credentials. It already does that
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 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.
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...
Please avoid the snark.
I read the readme in full, I think that's an appropriate level of effort. Your link also still doesn't answer it, though it hints: 'A migrated .env is a live mount (a named pipe), not a plain file'. So is that a file system driver, or...?
Even https://github.com/jitpass/jit/blob/main/docs/getting-starte... says it's a local encrypted store - and that's repeated many times across the docs Claude-style - but it doesn't explain the mechanism whereby reading a file gets the results from that store.