Show HN: Laptop is the last place your secrets are still in plaintext

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.

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.

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...

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/

What could possibly go wrong?

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.

I don't get why you would have PRODUCTION secrets in those local .env files. It should only be dev tokens.

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.

You can do some of this with 1Password as well btw. Looks nice!

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

I am actually building the exact same thing- encrypted vaults for files or folders, encrypted with a biometric gated key in the Secure Enclave!

I don't know about how secure this is, but I just love the UX. Scanning and process grant are great features UX-wise.

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.

Interesting idea! How do you achieve it? Some kind of file system driver that recognises the calling process?

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.

on Linux use systemd-credentials. It already does that

[flagged]