I made this package because it was requested by someone. And honestly I did not wanted to use Docker for this. But I did not had time to figure out on how to install it without Docker…
Then why this package uses Docker? It’s because the developers of the core app do not support simple installation. And packaging without documentaion is time consuming.
So now that this has been fixed, the next step could be to somehow make the manual install option aware within the Yunohost community (I am not sure what is the best way for this, hopefully others can) and then hopefully a Lemmy package for Yunohost can grow from level 0 to level 6 or 7 or 8, and by doing so have much more “exposure” among Yunohost users.
Considering how many apps use docker nowadays, that really surprises me that they wouldn’t support it. There’s that linuxserver docker repository that’s packaged hundreds of applications for docker.
Yunohost is focused on easy install on among others a VPS. If the VPS provider runs OpenVZ or LXC in their infrastructure then Docker is either not possible, or with limitations or first needs tweaking by the provider.
Docker is not bad for security, unless you do insecure things like exposing your Docker socket or running random workloads as root, however those are just as insecure under systemd.
This is not insecure. It is surprising if you don’t know how containers work, but in a real deployment you’d only bind to localhost and use a reverse proxy and that is perfectly safe.
As I said this is surprising if you don’t know how containers work. This is similar from how e.g. virtual machine networking would trip you. As long as you know how to set things up properly, which is documented at length, Docker is not “insecure”.
How is this different from say, SystemD? It runs as root and has a larger attack surface.
The link you pointed out has every CVE for every application packaged as Docker image. Would you make the same point that APT or AppImage is insecure because there are insecure applications packaged that way?
It’s very different because SystemD does way more things than running containers.
Also, this is whataboutism.
The link you pointed out has every CVE for every application packaged as Docker image.
You could scan through the list and check for yourself which ones are due to docker itself.
Besides, I updated the link to filter out the spurious CVEs.
Would you make the same point that APT or AppImage is insecure because there are insecure applications packaged that way?
I would not… unless the tool itself was actively encouraging bad security practices, for example bundling dependencies, as Docker/AppImage/Flatpak/Snap do.
It is not whataboutism since SystemD is what you’ll use to run services if you don’t use Docker… If I say that mass transit is a terrible idea because it pollutes, and you point out that cars pollute even more, I can’t claim “whataboutism” to dismiss your argument.
Thats great, I didnt even know that Yunohost was blocked by our lack of documentation.
Thanks! It is very uncommon for Yunohost apps to use Docker. I’ve looked up some history about this :
So now that this has been fixed, the next step could be to somehow make the manual install option aware within the Yunohost community (I am not sure what is the best way for this, hopefully others can) and then hopefully a Lemmy package for Yunohost can grow from level 0 to level 6 or 7 or 8, and by doing so have much more “exposure” among Yunohost users.
I simply made a comment in the thread you linked haha
Nice, thanks ! :)
Considering how many apps use docker nowadays, that really surprises me that they wouldn’t support it. There’s that linuxserver docker repository that’s packaged hundreds of applications for docker.
deleted by creator
Yunohost is focused on easy install on among others a VPS. If the VPS provider runs OpenVZ or LXC in their infrastructure then Docker is either not possible, or with limitations or first needs tweaking by the provider.
docker is really bad for security and adds a lot of unnecessary complexity
Docker is not bad for security, unless you do insecure things like exposing your Docker socket or running random workloads as root, however those are just as insecure under systemd.
It has some weird behaviour, for example ufw rules dont apply to Docker.
This is not insecure. It is surprising if you don’t know how containers work, but in a real deployment you’d only bind to localhost and use a reverse proxy and that is perfectly safe.
Not insecure ? Here an old blog post about it https://blog.viktorpetersson.com/2014/11/03/the-dangers-of-ufw-docker.html btw, Docker also had/has Google DNS as fallback, so the moment your DNS servers fail to respond Docker uses Google, not very privacy friendly.
As I said this is surprising if you don’t know how containers work. This is similar from how e.g. virtual machine networking would trip you. As long as you know how to set things up properly, which is documented at length, Docker is not “insecure”.
Docker runs the whole daemon as root and has a large attack surface. Also, it has a lot of footguns that can mislead the user. Its security track record speaks for itself: https://www.cvedetails.com/product/28125/Docker-Docker.html?vendor_id=13534
How is this different from say, SystemD? It runs as root and has a larger attack surface.
The link you pointed out has every CVE for every application packaged as Docker image. Would you make the same point that APT or AppImage is insecure because there are insecure applications packaged that way?
It’s very different because SystemD does way more things than running containers. Also, this is whataboutism.
You could scan through the list and check for yourself which ones are due to docker itself. Besides, I updated the link to filter out the spurious CVEs.
I would not… unless the tool itself was actively encouraging bad security practices, for example bundling dependencies, as Docker/AppImage/Flatpak/Snap do.
It is not whataboutism since SystemD is what you’ll use to run services if you don’t use Docker… If I say that mass transit is a terrible idea because it pollutes, and you point out that cars pollute even more, I can’t claim “whataboutism” to dismiss your argument.
Here’s the corresponding page for SystemD: https://www.cvedetails.com/product/38088/Freedesktop-Systemd.html?vendor_id=7971 as you can see there are even more vulnerabilities, which makes sense as the attack surface is even larger.