3 ms·

> Also, note that you have just changed to a non-reproducible container Precisely, and that may be what stops many from just updating their images. I think ide

> Also, note that you have just changed to a non-reproducible container Precisely, and that may be what stops many from just updating their images. I think ideally we'd have centralised updates, perhaps just one a week, and then use tag for that week. You could do all this in-house, but it's a lot of work for small teams. Redundant work.

dsr_ 5y ago
In the end, what gets deployed is the responsibility of the entity doing the deployment. Maybe the organization wants to deploy the latest trunk on every commit. There are probably some situations where that is reasonable. Those situations probably shouldn't involve people's money, privacy or safety. Setting up a two-stage local repository isn't very hard. The intake side gets updates from upstream, and the deployment side gets updates from the intake side when the packages have been reviewed and hopefully tested. Do this for everything with an external upstream -- Ruby gems, Python modules, JS libraries, whatever -- and you have insulated yourself against supply-chain attacks. As a bonus, if your leftpad function just goes missing upstream, you still have a full copy in your deployment repository, and will until you decide it's time to implement your own.
- mrweasel 5y ago
  > In the end, what gets deployed is the responsibility of the entity doing the deployment. Yes and no, I don't disagree, but remember classic hosting, semi-managed infrastructure still exists. We often get container images delivered and are responsible for the operational side of things, but we have no control of what is actually inside the containers. Sure we can make requests, or inform a customer that we believe what they are doing isn't safe. Ideally we could reject a request to run a container, but in reality that's not really an option. That shifts the responsibility of security more in the direction of the developers and they often do not have regular patch management as a priority.
  - dsr_ 5y ago
    If your organization isn't in control of the software you are running, you are a service provider and you have to treat them as potentially hostile external entities. Your responsibility is for the infrastructure, and you must explicitly disclaim responsibility for the functionality and security of anything inside the containers. This is, incidentally, the antithesis of "devops".
jrochkind1 5y ago
> You could do all this in-house, but it's a lot of work for small teams. Redundant work. What's the alternative?
- WJW 5y ago
  Right now the alternative seems to be "ignore the problem". :)
  - jrochkind1 5y ago
    Interesting, thank you! I still don't use containers (working on very small teams), and as I've tried to get into it, this is one of the questions I had where I was sure I was missing something and couldn't figure out what everyone else did... this is making me feel a lot more competent! (Although questioning the reasonableness of our industry!).

dsr_ 5y ago

In the end, what gets deployed is the responsibility of the entity doing the deployment. Maybe the organization wants to deploy the latest trunk on every commit. There are probably some situations where that is reasonable. Those situations probably shouldn't involve people's money, privacy or safety. Setting up a two-stage local repository isn't very hard. The intake side gets updates from upstream, and the deployment side gets updates from the intake side when the packages have been reviewed and hopefully tested. Do this for everything with an external upstream -- Ruby gems, Python modules, JS libraries, whatever -- and you have insulated yourself against supply-chain attacks. As a bonus, if your leftpad function just goes missing upstream, you still have a full copy in your deployment repository, and will until you decide it's time to implement your own.

mrweasel 5y ago
> In the end, what gets deployed is the responsibility of the entity doing the deployment. Yes and no, I don't disagree, but remember classic hosting, semi-managed infrastructure still exists. We often get container images delivered and are responsible for the operational side of things, but we have no control of what is actually inside the containers. Sure we can make requests, or inform a customer that we believe what they are doing isn't safe. Ideally we could reject a request to run a container, but in reality that's not really an option. That shifts the responsibility of security more in the direction of the developers and they often do not have regular patch management as a priority.
- dsr_ 5y ago
  If your organization isn't in control of the software you are running, you are a service provider and you have to treat them as potentially hostile external entities. Your responsibility is for the infrastructure, and you must explicitly disclaim responsibility for the functionality and security of anything inside the containers. This is, incidentally, the antithesis of "devops".

jrochkind1 5y ago

> You could do all this in-house, but it's a lot of work for small teams. Redundant work. What's the alternative?

WJW 5y ago
Right now the alternative seems to be "ignore the problem". :)
- jrochkind1 5y ago
  Interesting, thank you! I still don't use containers (working on very small teams), and as I've tried to get into it, this is one of the questions I had where I was sure I was missing something and couldn't figure out what everyone else did... this is making me feel a lot more competent! (Although questioning the reasonableness of our industry!).