4 ms·

> 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

by Faaak 1mo ago

bukershok 1mo ago
[dead]
necovek 1mo 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 1mo 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 1mo 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.

> 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

by Faaak 1mo 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 1mo ago

[dead]

necovek 1mo 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 1mo 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 1mo 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.