4 ms·

> Why do I have to elaborate? Because some of us have never heard of devcontainers as a named concept with its own spec until now. I've been running my dev ser

> Why do I have to elaborate? Because some of us have never heard of devcontainers as a named concept with its own spec until now. I've been running my dev servers inside containers for a long time now (using JetBrains IDEs!), but have never heard of this before. > It is well known that a container offers a sandbox and process isolation. No, actually, it's well known that containers don't do that. It's one of the first things you learn when you start learning about containers—they are not virtual machines and are not suitable for running untrusted code, because they share a kernel with the host. I just read through the introduction to devcontainers and there are lots of benefits it discusses but security isn't one of them: https://containers.dev/ https://containers.dev/

OutOfHere 2y ago
> security isn't one of them Oh but it is. If there is harmful data-stealing software running in the container, it will remain isolated to the container. And if the kernel is shared with the host, that's a read-only share.
- fragmede 2y ago
  > remain isolated to the container. Assuming the code that implements the containerization is 100% bug free and there are no container escapes. I would not bet my user's safety purely on that assumption.
  - acdha 2y ago
    This is as useful as saying that seat belts do not make you safer because people still die in crashes. Containers are not perfect but if you’re starting from the conventional position where you’re one wrong package install away from an attacker having arbitrary access to your account and data, they’re a significant immediate improvement and a good foundation for further improvement.
    - OutOfHere 2y ago
      Yes, exactly. JetBrains fanboys will prefer to remain blind to it, however, not realizing that the free version of JetBrains isn't competitive anymore against VSCode.
      - simion314 2y ago
        People pay for JetBrains instead of the free VS Code, and there are reasons for that, like IDE features and quality. Anyway there is no need to start an IDE war here, use whatever works for you and your coding, but I am sure that a small company can't offer free stuff and survive like big tech can do, so as a paying customer I want them to survive and make good products rather to give free shit to people that don't want to pay for their tools.
        OutOfHere 2y ago
        VSCode has raised the bar of what to expect from a free IDE in terms of container integrations. JetBrains has fallen behind, and is sticking to a decade old standards. I have no problem with the paid versions of JetBrains IDEs which I think are great, but to pay, one has to first find value in the free version (which is now lacking).
- lolinder 2y ago
  I think you're missing my point: you are saying that it is one of the benefits, but they don't because it isn't one. Containers are not a security solution for running untrusted code. You saying they are does not make it so. > And if the kernel is shared with the host, that's a read-only share. No, it's not, the kernel is reading and writing files constantly for the container. A bug in the kernel could be exploited to break the sandbox, which isn't possible in a true VM.
  - OutOfHere 2y ago
    There is no such thing as perfect security. Partial security is much better than none at all. Containers go a long way in this regard. All code is untrusted.
    - lolinder 2y ago
      > Partial security is much better than none at all. Only if you don't let down your guard because it's "secure". Again, there's a reason why they don't claim it's secure and everyone says to not treat containers as a sandbox.
      - OutOfHere 2y ago
        The only people here who are letting their guard down are ones who're not even using a container/jail/VM for each project. JetBrains encourages this by not providing the container integration features for free.
        lolinder 2y ago
        We're going in circles and I'm done engaging with you.
        OutOfHere 2y ago
        [flagged]
- simion314 2y ago
  >Oh but it is. If there is harmful data-stealing software running in the container, it will remain isolated to the container. And if the kernel is shared with the host, that's a read-only share. And what protects the production server when you deploy the evil packages?

OutOfHere 2y ago

> security isn't one of them Oh but it is. If there is harmful data-stealing software running in the container, it will remain isolated to the container. And if the kernel is shared with the host, that's a read-only share.

fragmede 2y ago
> remain isolated to the container. Assuming the code that implements the containerization is 100% bug free and there are no container escapes. I would not bet my user's safety purely on that assumption.
- acdha 2y ago
  This is as useful as saying that seat belts do not make you safer because people still die in crashes. Containers are not perfect but if you’re starting from the conventional position where you’re one wrong package install away from an attacker having arbitrary access to your account and data, they’re a significant immediate improvement and a good foundation for further improvement.
  - OutOfHere 2y ago
    Yes, exactly. JetBrains fanboys will prefer to remain blind to it, however, not realizing that the free version of JetBrains isn't competitive anymore against VSCode.
    - simion314 2y ago
      People pay for JetBrains instead of the free VS Code, and there are reasons for that, like IDE features and quality. Anyway there is no need to start an IDE war here, use whatever works for you and your coding, but I am sure that a small company can't offer free stuff and survive like big tech can do, so as a paying customer I want them to survive and make good products rather to give free shit to people that don't want to pay for their tools.
      - OutOfHere 2y ago
        VSCode has raised the bar of what to expect from a free IDE in terms of container integrations. JetBrains has fallen behind, and is sticking to a decade old standards. I have no problem with the paid versions of JetBrains IDEs which I think are great, but to pay, one has to first find value in the free version (which is now lacking).
lolinder 2y ago
I think you're missing my point: you are saying that it is one of the benefits, but they don't because it isn't one. Containers are not a security solution for running untrusted code. You saying they are does not make it so. > And if the kernel is shared with the host, that's a read-only share. No, it's not, the kernel is reading and writing files constantly for the container. A bug in the kernel could be exploited to break the sandbox, which isn't possible in a true VM.
- OutOfHere 2y ago
  There is no such thing as perfect security. Partial security is much better than none at all. Containers go a long way in this regard. All code is untrusted.
  - lolinder 2y ago
    > Partial security is much better than none at all. Only if you don't let down your guard because it's "secure". Again, there's a reason why they don't claim it's secure and everyone says to not treat containers as a sandbox.
    - OutOfHere 2y ago
      The only people here who are letting their guard down are ones who're not even using a container/jail/VM for each project. JetBrains encourages this by not providing the container integration features for free.
      - lolinder 2y ago
        We're going in circles and I'm done engaging with you.
        OutOfHere 2y ago
        [flagged]
simion314 2y ago
>Oh but it is. If there is harmful data-stealing software running in the container, it will remain isolated to the container. And if the kernel is shared with the host, that's a read-only share. And what protects the production server when you deploy the evil packages?