But here’s the thing: containers - like so many other mechanisms - suffer from supply-chain risks due to reduced validation to the degree assumed and required compared to, say, good packaging that integrates with the resident source of truth on a given system. Containers, like so many other risky mechanisms that dates back to CPAN or earlier, cannot exist in a secure environment.
For those of us working where we can to minimize repair/recovery work through best practice, Immich cannot be run.
I know there’s a homebrew workaround, but given it’s external to the dev effort it’s a risk that it won’t suddenly work as a reliable update resource; and that risk stymies uptake for us.
Now, I know I’ve suggested there’s imperfection in a number of favourite technologies and methods, and that’s fine. If downvotes is how you defend these sacred cows, I understand.
Sure supply chain attacks are a thing, but containers aren’t the issue. Any package delivery mechanism can suffer from it. Its up to you to verify those containers and/or build it yourself
Couldn’t you just lazy build your own images if you don’t trust the source?
Even then most of these containerized apps can be run perfectly fine as a host binary, you just have to make your own start script and a systemd unit which isn’t that bad.
You could then build a completely custom image if you’d like, or move it into a VM if you don’t like the idea of running it baremetal.
@corsicanguppy@sonofearth People concerned about this kind of thing could sponsor distributions to create native packages. For example, hire a debian developer to package and include immich in debian.
I’ve personally been meaning to package navidrome for debian for several years now, but other things have taken priority.
I dearly wish to use and support this app.
But here’s the thing: containers - like so many other mechanisms - suffer from supply-chain risks due to reduced validation to the degree assumed and required compared to, say, good packaging that integrates with the resident source of truth on a given system. Containers, like so many other risky mechanisms that dates back to CPAN or earlier, cannot exist in a secure environment.
For those of us working where we can to minimize repair/recovery work through best practice, Immich cannot be run.
I know there’s a homebrew workaround, but given it’s external to the dev effort it’s a risk that it won’t suddenly work as a reliable update resource; and that risk stymies uptake for us.
Now, I know I’ve suggested there’s imperfection in a number of favourite technologies and methods, and that’s fine. If downvotes is how you defend these sacred cows, I understand.
Sure supply chain attacks are a thing, but containers aren’t the issue. Any package delivery mechanism can suffer from it. Its up to you to verify those containers and/or build it yourself
Yup. Whoever backdoored xz was very close to getting it into production. The only reason they got caught was a slight performance regression and an inquisitive and dedicated developer. https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/
Some years ago, a backdoor made it into Gentoo. https://www.zdnet.com/article/linux-infection-proves-windows-malware-monopoly-is-over-gentoo-ships-backdoor-updated/
Couldn’t you just lazy build your own images if you don’t trust the source?
Even then most of these containerized apps can be run perfectly fine as a host binary, you just have to make your own start script and a systemd unit which isn’t that bad.
You could then build a completely custom image if you’d like, or move it into a VM if you don’t like the idea of running it baremetal.
@corsicanguppy @sonofearth People concerned about this kind of thing could sponsor distributions to create native packages. For example, hire a debian developer to package and include immich in debian.
I’ve personally been meaning to package navidrome for debian for several years now, but other things have taken priority.