Posted by bukershok 3 hours ago
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.
As pointed to me by a friend, this is one reason not to give in to the convenience of the secrets manager you already use.
My use case for fnox with keepassdb back-end was partially validated but as I mentioned elsewhere in the thread, having to set master password in an env var is a bit of snag for the workflow.
i know other people partitioning their secrets into multiple keepassx vault files, so the argument about using the same password manager can be interpreted differently.
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.
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.
Can you just.. not?
The intended purpose of the tool is perfectly clear. There was never any confusion about it.
This nonsensical attitude is thankfully dying out in favor of more sophisticated approaches.
Sounds unconvincing. Can you elaborate further?
PS: Thank you!
appreciation and OS aside, systemd-creds relays long-lived creds into long-lived processes, and author's AI slop attempts at short-lived/on-demand injections. Apparently, author's AI slop gets a lot of iterations, but has not much of external scrutiny yet.
echo -n "sk-proj-12345..." | systemd-creds encrypt --with-key=tpm2 --name=openai_key - openai.cred
And then at runtime export OPENAI_API_KEY=$(sudo systemd-creds decrypt openai.cred)