It would be a possibility, for safety to create a new directory only for brandy 3rd-party-software like skype, Google Chrome, Swift, and else Software where huge companies are Sponsors.
This would then mean, to create a second sources list for 3rd-party-links. Carl-Valentin Schmitt <cv.schm...@gmail.com> schrieb am Do., 4. Okt. 2018, 01:06: > in /usr only ?... > > I thought therefore in later years Linux had created /opt ? > > > > Lars Wirzenius <l...@liw.fi> schrieb am Mi., 3. Okt. 2018, 19:19: > >> The problem: when a .deb package is installed, upgraded, or removed, >> the maintainer scripts are run as root and can thus do anything. >> >> Sometimes what they do is an unwelcome surprise to the user. For >> example, the Microsoft Skype .deb and the Google Chrome .deb add to >> the APT sources lists and APT accepted signing keys. Some users do not >> realise this, and are unpleasantly surprise. >> >> (Note that I'm not saying Microsoft or Google are doing something >> nefarious here: they're trying to make sure security updates for their >> packages will be deployed to user's system; this seems like a worthy >> goal. But it's a surprise to some users.) >> >> I don't think it's good enough to say the user shouldn't install >> third-party packages. It's not even good enough to say the user should >> use flatpaks or snaps instead: not everything can be packaged that >> way. Debian's own packages can have equally unwelcome surprises. >> >> Imagine a package that accidentally removes /var, but only under >> specific conditions. You'd hope that Debian's testing during a release >> cycle would catch that, but there's not guarantee it will. (That's a >> safety issue more than a security issue.) >> >> A suggestion: we restrict where packages can install files and what >> maintainer scripts can do. The default should be as safe as we can >> make it, and packages that need to do things not allowed by the >> default should declare they that they intend to do that. >> >> This could be done, for example, by having each package labelled with >> an installation profile, which declares what the package intends to do >> upon installation, upgrade, or removal. >> >> * default: install files in /usr only >> * kernel: install files in /boot, trigger initramfs >> * core: can install files anywhere, trigger anything >> * maintained-by-liw: full power to do anything >> >> This might be implemented in various ways. For example, dpkg could >> create a temporary directory, and bind mount the directories the >> profile indicates are needed, into a temporary shadow of the full >> system. Maintainer scripts would be run in the shadow environment. >> Thus, if they try to do something that isn't allowed by the packages >> profile, they can't. >> >> The profile should be in the Packages file, and each apt signing key >> should specify which repository (i.e., Packages file) it applies to. >> There may be per-key restrictions for what profiles are allowed. >> >> This is a quick thought, while I was trodding in the dark, wet, cold >> evening to the grocery store. It's not a full specification, and it >> may well not solve all problems that may happen when installing a >> broken or malicious .deb. I'd like for us to solve at least the more >> glaring problems, rather than throw our hands up and say it's to >> difficult a problem. I'd like to be safe from my own mistakes, and if >> that means our users are more safe and secure as well, that's a good >> thing. >> >> -- >> I want to build worthwhile things that might last. --joeyh >> >
