4 ms·

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

by hnlmorg 2mo ago

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

bukershok 2mo ago
hnlmorg, i must disagree with you on this one, that most people do not have passwords in plain text. If you a developer or just using API in your day to day you will have secretes in plaintext on your projects.
- hnlmorg 2mo ago
  This isn’t aimed at people who aren’t developers nor use APIs in their day-to-day. So it seems odd to include mum-and-pop macOS users in your context.
  - bukershok 2mo ago
    My bad I misread your quote blocks we're actually saying the exact same thing. Thanks for defending the use case and highlighting the ~/.aws point.
necovek 2mo ago
Your local development machine will have the source code or images or IaaC configuration that you push to GH/AWS — a rogue agent can just modify that and wait for you to authorize the next push. 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.
- hnlmorg 2mo ago
  > Your local development machine will have the source code or images or IaaC configuration that you push to GH/AWS — a rogue agent can just modify that and wait for you to authorize the next push. 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.
seba_dos1 2mo ago
> This surprises me The world does not end on SaaS.

by hnlmorg 2mo ago

bukershok 2mo ago

hnlmorg, i must disagree with you on this one, that most people do not have passwords in plain text. If you a developer or just using API in your day to day you will have secretes in plaintext on your projects.

hnlmorg 2mo ago
This isn’t aimed at people who aren’t developers nor use APIs in their day-to-day. So it seems odd to include mum-and-pop macOS users in your context.
- bukershok 2mo ago
  My bad I misread your quote blocks we're actually saying the exact same thing. Thanks for defending the use case and highlighting the ~/.aws point.

necovek 2mo ago

Your local development machine will have the source code or images or IaaC configuration that you push to GH/AWS — a rogue agent can just modify that and wait for you to authorize the next push. 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.

hnlmorg 2mo ago
> Your local development machine will have the source code or images or IaaC configuration that you push to GH/AWS — a rogue agent can just modify that and wait for you to authorize the next push. 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.

seba_dos1 2mo ago

> This surprises me The world does not end on SaaS.