4 ms·

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 pas

by necovek 2mo ago

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.

idoubtit 2mo ago
* 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.
Faaak 2mo ago
> 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
- bukershok 2mo ago
  [dead]
- necovek 2mo ago
  I guess you missed my "containerisation" point: if not restricted, every rogue package or agent has access to your full $HOME too. A secret is there to protect access to data you care about. If that data is there, well, not much achieved. 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.
  - hnlmorg 2mo ago
    > I guess you missed my "containerisation" point: if not restricted, every rogue package or agent has access to your full $HOME too. A secret is there to protect access to data you care about. If that data is there, well, not much achieved. 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.
    - necovek 2mo ago
      Thanks for the lesson on what each of those technologies is: are you claiming they cannot be used to achieve the effect of disallowing access to a filesystem area for a process (like an agent)? 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.
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.

by necovek 2mo ago

idoubtit 2mo ago

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

Faaak 2mo ago

> 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

bukershok 2mo ago
[dead]
necovek 2mo ago
I guess you missed my "containerisation" point: if not restricted, every rogue package or agent has access to your full $HOME too. A secret is there to protect access to data you care about. If that data is there, well, not much achieved. 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.
- hnlmorg 2mo ago
  > I guess you missed my "containerisation" point: if not restricted, every rogue package or agent has access to your full $HOME too. A secret is there to protect access to data you care about. If that data is there, well, not much achieved. 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.
  - necovek 2mo ago
    Thanks for the lesson on what each of those technologies is: are you claiming they cannot be used to achieve the effect of disallowing access to a filesystem area for a process (like an agent)? 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.

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.