On Tue, 2018-02-27 at 14:13 +0100, Didier 'OdyX' Raboud wrote: > > - we could ship those applications not as .deb but as container > > and let them have their own lifecycle > > tl;dr: a new package format is needed, with a new non-suite-specific > repository is needed to bring the Debian added-value to these > ecosystems. To me 'container' is the right solution. The problem is Debian doesn't support building light weight containers well. In fact nobody does. Docker makes an attempt, but distributing static file system images that have to get their security updates installed by replacing the entire image is ick. If I were do the entire thing over again, I would break Debian up into a series of rings. In the inner most ring is like the inner most ring of Linux. It's filesystem(s) is readonly to all other rings. In it sits the code for dpkg, But dpkg wouldn't do much beyond pulling down packages and their security upgrades into a /debian directory, which would look rather like /pool on the mirrors now, but the .deb's and .dsc's would being directories rather than tar archives. Other containers would run above this. They create their /usr file systems by linking into dpkg's /debian directory (which is readonly to them). Maintainer scripts would run when these are containers are built. This means dpkg is no longer running maintainer scripts, so just like an Android application a malicious package is limited in the harm it could cause and in particular uninstall would always work. These containers would be notified when packages they are running have security upgrades installed, so they can swap to the new versions at a convenient time. We still get to keep the "one copy of each library so we only have to fix a vulnerability once" advantage Debian has now (and other current solutions notably lack). Anybody who has fiddled with containers will have no trouble filling in the rest of the picture. It gives us two things: much better security and a faster way to build containers (because the unpacking step has already been done). I realise it sounds grandiose and far fetched, however it can be broken down into small(ish) steps. Step 1 would be having dpkg unpack everything to the /debian directory (including the state it currently stores under /var) rather than installing it in place, and just placing links in /usr, /etc and so on. (I'm am optimist in that I think you could pull that off without too many things noticing.) Step 2 would be to isolate /debian, so the rest of the world sits in its own container and run the maintainer scripts from within that container. (I'm such a optimist that even I think doing this wouldn't require many changes beyond dpkg.) The next steps would be moving each application into it's own container. They would be much harder, but I suspect once you've done the refactoring to make dpkg maintained containers possible, the thing would take on a life of it's own. In this world, vdeb's are just packages that apt will only permit to be installed in a container the user has somehow marked as insecure (means no Debian QA, ie no security patches). Anybody thinking "yeah, but not that insecure" should probably read this bug report: https://github.com/npm/npm/issues/19883 The idea Debian would by default prevent that from trashing my laptop is real appealing.
Description: This is a digitally signed message part