On 12/02/2019 19.41, Jim Henderson wrote:
On Tue, 12 Feb 2019 11:25:38 +0100, Carlos E. R. wrote:
On 11/02/2019 21.13, Jim Henderson wrote:
On Mon, 11 Feb 2019 21:11:07 +0100, Carlos E. R. wrote:
I mean, if we want to make sure there are no problems in their path, let's remove usernames and passwords as well. Passwords are just an obstacle to a good user experience, after all.
Well, there is the setting easy/secure/paranoid. It could be expanded.
And who are the users going to blame when their system is compromised?
They're not going to own it. They're going to blame our default settings.
I'm not saying that.
I'm saying that we could expand these choices. If you (I mean, the user) choose a setting in YaST like "I want easy setup even if not fully secure at my own risk", and that setting includes not blacklisting modules, and other things that may arise, that would be another solution to our problem.
I'm not actually proposing it, I'm only thinking aloud, wondering.
Yes, I get that - but my answer still applies. If we provide an 'easy' button that leaves the system insecure and they are compromised, even with all the warnings in the world, they're going to say "I picked 'easy' because I wanted it easy. I assumed that the system would still be secure." and the project will get the blame.
Nope. I said the label would be something like "easy and not secure" ;-) It would need a new yast module to do fine grained choices.
Maybe they could all be put in a separate kernel package - kernel-default- legacyfilesystems or something and don't install it by default unless one of those filesystems is detected on the system. Then make a lot of noise about "we're installing this package, but know that you may be open to security exploits as a result of using unmaintained, legacy filesystems".
That could be a good alternative.
That's a reasonable solution as well - make them available where they're needed, and don't make them available where they're not.
-- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)