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
@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.
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.
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/
@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.
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.