Show HN: Laptop is the last place your secrets are still in plaintext
github.com
github.com
* 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 don't see the point. Once your home is unlocked, every process can see the file contents
Eg. imagine there's the source code for a service you deploy to AWS — rogue sw can modify it letting you unknowingly update it the next time (or why do you have those AWS keys anyway?).
But not if they are part of non-classic Snap on Ubuntu or properly containerised Flatpak (on Linux, at least), or in a VM or LXC/Docker/Podman container.
There can be multiple processes that might need access to a project root and thus you might still find utility in something like these even inside a container.
In security, we call this "defence in depth".
> Eg. imagine there's the source code for a service you deploy to AWS — rogue sw can modify it letting you unknowingly update it the next time (or why do you have those AWS keys anyway?).
Sure, but then you also wouldn't be using version control either. Nor checking the dryrun plans before applying your new IaC. So it sounds like you're not following any form of rigour at all in such a hypothetical scenario.
> But not if they are part of non-classic Snap on Ubuntu or properly containerised Flatpak (on Linux, at least), or in a VM or LXC/Docker/Podman container.
Nice word soup there but you're misunderstanding the technologies.
- Snap and Flatpak target different problem spaces (application packaging for distribution).
- VMs by themselves wouldn't achieve much because you'd need mounted paths eg if you want one agent to manage code and not also have Terraform to run inside that same VM. While you could manage mounted paths manually, it's really not worth the effort when Docker gives you an easy UI out-of-the-box
- LXC is pretty barebones. It would be like creating a VM in the effort to build repeatable ephemeral environments from it. You can do it, but why would you when OCI has an easy-to-use ecosystem already?
- Docker/Podman, if you wanted to make the distinction, then why not just say "OCI"?
---
I do think scepticism in tech can be healthy. But what you're doing isn't that. It's just dismissing the tech without any effort to understand it. And thus your arguments against it contain a multitude of flaws.
They have different default behavior (and levels of isolation), which is why I mentioned a few popular choices, but there is more (LXD and Incus, for instance).
As far as "following any form of rigour", that's exactly what's happening for many with a move to coding agents — one-shotted diffs are so big, that people cannot keep the focus and introducing a tiny one-liner (eg. one that copied your AWS secret to innocent-file.sig) would likely go unnoticed. So yes, even if you used a VCS and glanced over your dry run IaC output, you'd easily be fooled.
Caring about reducing impact of human "mistakes" (due to lack of attention), we also call that defense in depth.
> * 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 impenetrable, 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 or hosted on-prem) is where the actual data, compute and infrastructure exist.
If you a developer or just using API in your day to day you will have secretes in plaintext on your projects.
I'd also consider short-lived tokens "in-memory during use", even if 8h is not very short.
If you have AWS keys but do not have anything you use them for, then yes, a tool like this will help.
However, the tool seems to implement per-provider handling, meaning large surface area and new risks replacing old ones. Even standard, trusted crypto libraries are frequently misused in insecure ways.
I can certainly explore the code, but as it is a "Show HN", I'd like the author to show it ;)
My point is to understand clearly where does author believe this tool has merit.
Yes, but that's then concerning yourself with the remote state and thus the opposite of the sentiment you made when you said:
> I find that I worry more about my local data compared to my remote data
> I'd also consider short-lived tokens "in-memory during use", even if 8h is not very short.
I never said 8hrs was short. And once again, nobody is talking about in-memory use. If that's a legitimate risk you need to cover then VMs or literal air-gapped systems are your only solution. But for clear text in-memory to be a risk you'd then need to be running untrusted executables are root. Which then raises the legitimate question of "why the f*k are you doing that on your main development machine in the first place?!!"
> However, the tool seems to implement per-provider handling, meaning large surface area and new risks replacing old ones. Even standard, trusted crypto libraries are frequently misused in insecure ways.
It sounds more like you're commenting without researching this tool.
Scepticism is definitely a valuable asset when it comes to security. But what you're doing here isn't scepticism. It's just dismissive and presumptuous. The good points you're trying to make are undermined by the really obvious flaws in your assumptions.
> I can certainly explore the code, but as it is a "Show HN", I'd like the author to show it ;)
They have. It's literally the Show HN link to the source and it includes a fair amount of documentation to support the product. The questions of trust you keep raising can only be proven via an independent audit of the code, for example, yourself reading through it.
> My point is to understand clearly where does author believe this tool has merit.
That's right there in the README. And I think you already know this because you touched on another solution to the same problem when you discussed containerisation. Which then brings me back to my earlier point about constructive scepticism vs lazy dismissal.
That's what discussion is about, no? Or should I not ask questions before auditing and understanding the entire codebase?
I am not sure what assumptions was I making: can you point to one?
The world does not end on SaaS.
And what would be the other concerns? That you have a possibly malicious piece of software reading your secrets that you haven't encrypted?
That's literally the raison d'etre of this tool. By definition it's better than nothing.
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...
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/
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…
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.
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 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/
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.
Other 1pass is a great UX. It was even greater before Electron refactor and non-subscription model.
Especially the 8 hours valid aws SSO access token felt super risky to have available in plain text. Would those those temporary credentials work as well?
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?
A bit uncomfortable in leaving a secret in the history. Hence I was looking for a tool like this.
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.
But even that aside, there's still merit in protecting rogue processes from trashing your non-production environments
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.
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.
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)
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.
PS: Thank you!