Am 30.01.19 um 17:44 schrieb John Paul Adrian Glaubitz:

As long as all it takes is uncommenting those lines, I don't see any problems :).

+1 Regards -- Till -- Dipl.-Inform. Till Dörges doerges@pre-sense.de Tel. +49 - 40 - 244 2407 - 0 Fax +49 - 40 - 244 2407 - 24 PRESENSE Technologies GmbH Sachsenstr. 5, D-20097 HH Geschäftsführer/Managing Directors AG Hamburg, HRB 107844 Till Dörges, Jürgen Sander USt-IdNr.: DE263765024 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, 30 Jan 2019 17:58:31 +0100, Ondrej Holecek wrote:

On Wednesday, January 30, 2019 5:41:17 PM CET Martin Wilck wrote:

...

SUSE will blacklist a number of legacy and/or less frequently used file systems by default on SLES for security reasons.

The proposed list can be seen here:

https://github.com/openSUSE/suse-module-tools/pull/5/commits/8cb42fb6658f210 cb8c955d584a65f7b041c0575

I was surprised to see F2FS on the list. If this email should count as a vote, I would like to see F2FS not blacklisted.

Actually f2fs is currently even no longer built. It's disabled for Leap as well. See details in https://bugzilla.opensuse.org/show_bug.cgi?id=1109665 Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michael Ströder composed on 2019-01-30 12:04 (UTC-0500):

Felix Miata wrote:

...

As an OS/2 user, HPFS support was something that attracted me to SuSE many moons ago. > [..] Please don't add the annoyance that blacklisting HPFS would become.

Is commenting out HPFS from the black-list file really such a big annoyance for you? Especially since running OS/2 as multi-boot is a really rare use-case today.

I'm not speaking only for myself. If it was only one or two PCs, or people who even know what blacklisting is, it might not be a lot of trouble, but I don't see that as the case.

Personally I'd prefer to protect the majority of users by blacklisting unmaintained kernel drivers.

I'd guess the majority of non-corporate continuing OS/2 users are also Linux multibooters, so it's not so rare. OS/2 and its successor incarnations offer things no other OS or DE has attempted. It's a significant userbase, both corporate and non-corporate. If it wasn't, eComStation wouldn't have existed, and https://www.arcanoae.com/ wouldn't exist today. I can't do with Linux what I am doing almost constantly with OS/2. I have to have both, and interop between them is already plenty bad compared with Linux to Windows and Mac. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Axel Braun composed on 2019-01-31 09:48 (UTC+0100):

Felix Miata composed:

...

I'd guess the majority of non-corporate continuing OS/2 users are also Linux multibooters, so it's not so rare. OS/2 and its successor incarnations offer things no other OS or DE has attempted. It's a significant userbase, both corporate and non-corporate. If it wasn't, eComStation wouldn't have existed, and https://www.arcanoae.com/ wouldn't exist today.

Sounds like 'The return of the Walking Dead' I dropped OS/2 20 years ago, most companies I know of - mostly banks - have kicked it either. So its market share should be around <estimate> 0,001% </estimate>

And yet there are enough to manage to have an annual convention: http://www.warpstock.org/

...

I can't do with Linux what I am doing almost constantly with OS/2. I have to have both, and interop between them is already plenty bad compared with Linux to Windows and Mac.

I don't know what this very special tasks are

Exceptionally functional orphan DOS apps learned 3 decades ago with no migration path that don't work in any other DOS emulation. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Jim- so far as I'm aware, thinking does not necessarily match reality. I couldn't tell you how many attend that conference, but I do wonder what a representative sample of (open)SUSE users would report as "necessary" file systems. Without such a sample this proposed change appears quite reckless. Best, Jim On Thu, 2019-01-31 at 16:45 +0000, Jim Henderson wrote:

On Thu, 31 Jan 2019 04:37:08 -0500, Felix Miata wrote:

...

And yet there are enough to manage to have an annual convention: http://www.warpstock.org/

I don't have a horse in this race, but going to the site for the Berlin 2018 conference doesn't make me think that this affects thousands of users. It makes me think it affects about 20. Small conference rooms, a relatively small lunch gathering. Makes me wonder what the actual attendance is.

The solution is simple - remove the filesystem from the blacklist. Seems like a really easy thing to do for something that's used by 20 people.

It's not like the filesystem module is not being built or included. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2019-01-31 at 18:46 -0000, Jim Henderson wrote:

On Thu, 31 Jan 2019 13:42:14 -0500, Jim E Bonfiglio wrote:

...

Hi Jim- so far as I'm aware, thinking does not necessarily match reality. I couldn't tell you how many attend that conference, but I do wonder what a representative sample of (open)SUSE users would report as "necessary" file systems. Without such a sample this proposed change appears quite reckless.

Well, like I said, I don't have a horse in this race. It seems to me like a sensible move, with an easy solution for those who really need these filesystems.

How will some user in the future that tries to mount something and gets told "unknown filesystem" that it is a blacklisted one? The error message doesn't say. - -- Cheers, Carlos E. R. (from openSUSE 15.0 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXFNFqBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVYLwAn3RYSRPxso5KOv1efQ0d Nrr/N56QAJ9TTjNFN786QKMiXHEHr3Apnttx4g== =0DXN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 31/01/2019 21.50, Jim Henderson wrote:

See Jeff's answer, Carlos. I'm not the one making the change.

I did not say you were.

But I'd also be inclined to RTFM for information like that, too.

Where? :-)

If I need a filesystem that isn't installed, my approach would be to look to see if it was included in the kernel package (which it sounds like it would be), and then to look at why it isn't auto-loading.

Ok, so look, read, study... Problems, delays.

That seems like common sense to me.

What doesn't seem like common sense to me is to load it on millions of installations where it isn't needed because a hundred (thousand, whatever small percentage use OS/2 in dual-boot configs with openSUSE) can't be bothered to uncomment a line in a blacklist file.

I'm not saying to keep the drivers. Did I? I only say that the users that need one of those filesystems in the future will be surprised and not know what to do. Ideally, the mount command would print information, or where to read more. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 31/01/2019 22.26, Michael Ströder wrote:

On 1/31/19 10:05 PM, Carlos E. R. wrote:

...

I'm not saying to keep the drivers. Did I? I only say that the users that need one of those filesystems in the future will be surprised and not know what to do.

But users will also be "suprised" when putting in a rogue USB stick which hits a security bug in an unmaintained file system driver.

True.

It's just a matter of weighing one against the other.

Personally I have a strong preference to mitigate attack vectors.

I agree. I only wonder if there is something that could be done to tell users what is happening at the moment it happens to them. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 31/01/2019 22.52, Jeff Mahoney wrote:

On 1/31/19 4:38 PM, Carlos E. R. wrote:

...

On 31/01/2019 22.26, Michael Ströder wrote:

...

On 1/31/19 10:05 PM, Carlos E. R. wrote:

...

I'm not saying to keep the drivers. Did I? I only say that the users that need one of those filesystems in the future will be surprised and not know what to do.

But users will also be "suprised" when putting in a rogue USB stick which hits a security bug in an unmaintained file system driver.

True.

...

It's just a matter of weighing one against the other.

Personally I have a strong preference to mitigate attack vectors.

I agree.

I only wonder if there is something that could be done to tell users what is happening at the moment it happens to them.

When they're attacked or when the module fails to load?

When it fails to load, somehow point to somewhere to read what is going on, why it was disabled, how to enable at his own risk, etc :-) I'm not saying to enable to keep them enabled. Just wondering if it is possible to inform users of the situation when they are surprised by not being able to mount one of them. If it is not possible, well, it is not possible. Maybe a message on syslog from kernel when module is loaded to tell it is risky, please read "/path/file"? Maybe a message by mount command? I don't know. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 31/01/2019 22.52, Jeff Mahoney wrote:

On 1/31/19 4:05 PM, Carlos E. R. wrote:

...

On 31/01/2019 21.50, Jim Henderson wrote:

...

...

Ideally, the mount command would print information, or where to read more.

The mount command doesn't have that context. It calls mount(2) and the kernel requests that userspace load the module. Then mount(2) returns -ENODEV, which is documented in the mount(2) man page as "file system type not configured in the kernel." If the module isn't loaded, the module doesn't register as a file system type, and then there's no difference between "mount -t sadlksjadlk" and "mount -t jfs".

mount(8) can't attempt to load the module itself since it may not have privileges to do that even if it weren't blacklisted.

Understood.

We can definitely document the blacklisting case in the mount(8) man page, though. It's probably possible to link with libkmod and check if the module was blacklisted, too.

That would be nice, thanks :-) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On Fri, Feb 1, 2019 at 12:04 PM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:

Am 31.01.19 um 22:52 schrieb Jeff Mahoney:

...

mount(8) can't attempt to load the module itself since it may not have privileges to do that even if it weren't blacklisted.

We can definitely document the blacklisting case in the mount(8) man page, though. It's probably possible to link with libkmod and check if the module was blacklisted, too.

I thought about

install foobarfs logger "this module is blacklisted in /<filename>, please see the comments there"

instead of

blacklist foobarfs

but I think this would also prevent manually loading the module which we of course do not want.

modprobe --ignore-install -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 1 Feb 2019 10:55:59 +0100 Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:

Am 01.02.19 um 10:36 schrieb Andrei Borzenkov:

...

...

I thought about

install foobarfs logger "this module is blacklisted in /<filename>, please see the comments there"

instead of

blacklist foobarfs

but I think this would also prevent manually loading the module which we of course do not want.

modprobe --ignore-install

Yes, but that is no longer "just load it manually" but "load it manually with special options". Which is easy, simple and logical for you and me, but maybe not for "Joe User" :-)

If the message or the blacklist file says so it is very logical. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 2019-02-01 at 12:48 +0100, Stefan Seyfried wrote:

Am 01.02.19 um 12:40 schrieb Michal Suchánek:

...

On Fri, 1 Feb 2019 10:55:59 +0100 Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:

...

Am 01.02.19 um 10:36 schrieb Andrei Borzenkov:

...

modprobe --ignore-install

Yes, but that is no longer "just load it manually" but "load it manually with special options". Which is easy, simple and logical for you and me, but maybe not for "Joe User" :-)

If the message or the blacklist file says so it is very logical.

even better: vbox-seife:~ # cat /etc/modprobe.d/99-jfs.conf install jfs logger -t modprobe "jfs logmessage"; echo "JFS disabled by blacklist.conf, use --ignore-install" vbox-seife:~ # modprobe jfs JFS disabled by blacklist.conf, use --ignore-install vbox-seife:~ # tail -1 /var/log/messages 20190201-12:46:01.8 modprobe: jfs logmessage

So we could log to syslog and to the terminal for interactive use.

Thanks for the suggestion, but sorry, I don't like that. "blacklist" is neat and clean. "install" opens up a can of worms. Look at the man page of modprobe.d: "install" is essentially deprecated. More issues with that suggestion: - The "echo" command is not printed to the console for users running mount(8); only users running modprobe see it. - With the "blacklist" approach, you can work around the problem with a plain "modprobe jfs". With the "install" approach, you now need to run "modprobe --ignore-install jfs". - It hasn't been the intention to prohibit "modprobe jfs". On the contrary, we explicitly allow / encourage users to do that to work around the blacklist entries if they need to. - generating or modifying (possibly arbitrary) "install" directives is significantly more complex then handling simple "blacklist" entries in %post. Well - I guess it comes down to commenting out, but we'd need to think it through thoroughly. I've proposed a log message printed by libmount when the ENODEV error is encountered in the blacklisting approach. The message looks like this: # mount /tmp/cramfs-img /mnt/img mount: /mnt/img: unknown filesystem type 'cramfs' (hint: possibly blacklisted, see mount(8)). (the first part is the standard message, the "hint" is appended if one of our "blacklist candidates" is encountered). I *think* this message would show up in the journal for GUI users. (not sure where, though). The man page then contains a paragraph about blacklisted file systems: -------- Blacklisted file systems In the Linux kernel, file system types are implemented as kernel modules. While many of these file systems are well main- tained, some of the older and less frequently used ones are not. This poses a security risk, because maliciously crafted file system images might open security holes when mounted either automatically or by an inadvertent user. The mount command prints "unsupported file system type 'somefs'" in this case, because it can't distinguish between a really unsupported file system (kernel module non-existent) and a blacklisted file system. Users who need the blacklisted file systems and therefore want to override the blacklisting can either load the blacklisted module directly: modprobe -v somefs or override the blacklist configuration by editing files under the /etc/modprobe.d directory. -------- Thanks Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Feb 1, 2019 at 12:56 PM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:

Am 01.02.19 um 10:36 schrieb Andrei Borzenkov:

...

...

I thought about

install foobarfs logger "this module is blacklisted in /<filename>, please see the comments there"

instead of

blacklist foobarfs

but I think this would also prevent manually loading the module which we of course do not want.

modprobe --ignore-install

Yes, but that is no longer "just load it manually" but "load it manually with special options". Which is easy, simple and logical for you and me, but maybe not for "Joe User" :-)

Joe User has no idea (s)he needs to run modprobe with or without options, less which module to load. So it does not change anything for Joe User. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday 2019-02-01 13:03, Luiz Fernando Ranghetti wrote:

...

Joe User has no idea (s)he needs to run modprobe with or without options, less which module to load. So it does not change anything for Joe User.

Joe User won't have these exotic filesystems installed in the first place ;)

Joe User isn't even the target audience for openSUSE I hear. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 01/02/2019 13.03, Luiz Fernando Ranghetti wrote:

Em sex, 1 de fev de 2019 às 10:00, Andrei Borzenkov <arvidjaar@gmail.com> escreveu:

...

On Fri, Feb 1, 2019 at 12:56 PM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:

...

Am 01.02.19 um 10:36 schrieb Andrei Borzenkov:

...

...

I thought about

install foobarfs logger "this module is blacklisted in /<filename>, please see the comments there"

instead of

blacklist foobarfs

but I think this would also prevent manually loading the module which we of course do not want.

modprobe --ignore-install

Yes, but that is no longer "just load it manually" but "load it manually with special options". Which is easy, simple and logical for you and me, but maybe not for "Joe User" :-)

Joe User has no idea (s)he needs to run modprobe with or without options, less which module to load. So it does not change anything for Joe User.

Joe User won't have these exotic filesystems installed in the first place ;)

If by "Joe user" we take "somebody that does not read here", we already know some that use jfs or os/2 ;-) -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

01.02.2019 0:52, Jeff Mahoney пишет:

On 1/31/19 4:05 PM, Carlos E. R. wrote:

...

Ideally, the mount command would print information, or where to read more.

The mount command doesn't have that context. It calls mount(2) and the kernel requests that userspace load the module. Then mount(2) returns -ENODEV, which is documented in the mount(2) man page as "file system type not configured in the kernel." If the module isn't loaded, the module doesn't register as a file system type, and then there's no difference between "mount -t sadlksjadlk" and "mount -t jfs".

modprobe could return dedicated exit code to indicate "module is blacklisted". request_module() returns exit code of user helper so it would return this error to caller. Caller (mount layer) currently ignores return value of request_module(), so it would need change to use and return it. Currently list of blacklisted modules is maintained in one package, list of modules for which to print warnings in another package (in different format) which almost inevitably leads to them differ over time. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 1/31/19 3:50 PM, Jim Henderson wrote:

See Jeff's answer, Carlos. I'm not the one making the change.

But I'd also be inclined to RTFM for information like that, too. If I need a filesystem that isn't installed, my approach would be to look to see if it was included in the kernel package (which it sounds like it would be), and then to look at why it isn't auto-loading.

That seems like common sense to me.

What doesn't seem like common sense to me is to load it on millions of installations where it isn't needed because a hundred (thousand, whatever small percentage use OS/2 in dual-boot configs with openSUSE) can't be bothered to uncomment a line in a blacklist file.

I think there's a misunderstanding here. The OS/2 modules aren't loaded on millions of installations where it isn't needed. The autoloading stuff doesn't load all of the file system modules -- it autoloads modules as they're needed. The problem is that they can be triggered by events that the admin generally wants to allow, like inserting a USB device or allowing users to mount file systems manually (e.g. singularity, or in containers). So say you have an unprivileged user craft an hpfs file system that exploits a lack of input validation and it escalates into privileged access. -Jeff -- Jeff Mahoney SUSE Labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I'm going to reorder this for clarity. On 1/31/19 9:50 PM, Jim Henderson wrote:

If I need a file system that isn't installed,

How does a non-expert user know that this is the problem? There's no such error message, AIUI. AFAICT it merely says "unknown FS".

But I'd also be inclined to RTFM for information like that, too. What manual? How do you know what to look for?

my approach would be to look to see if it was included in the kernel package

How would they do that? FWIW, as a Unix user for 31y and Linux user for 23y here, I'm not sure that *I* would know how to do that. TBH it stretched my knowledge just to get the freebie demo DVD of SLE12 that I got in my job interview to multi-boot alongside Win7, Ubuntu, Fedora and Arch on my testbed machine. I had to manually partition, manually set up a chainloaded bootloader -- stuff I've never had to do for any other distro.

(which it sounds like it would be),

How do you know that? Do you think a non-expert would know that?

and then to look at why it isn't auto-loading.

How would one get that far in the troubleshooting sequence to work out that this was the problem?

That seems like common sense to me.

I can assure you, no, it is not! :-)

What doesn't seem like common sense to me is to load it on millions of installations where it isn't needed

Then all modern OSes must dismay you, because that is how they work: including tens of thousands of drivers that 99% of people will never need, just so that they are there and the software works for the 1% who need them.

because a hundred (thousand, whatever small percentage use OS/2 in dual-boot configs with openSUSE)

Yes, I think it probably _is_ a very small proportion. OTOH, *SUSE is one of the oldest distros, and OS/2 is one of the oldest PC OSes, dating back to 1988 IIRC. Hardcore OS/2 users are old-timers. They are the sort of market *SUSE might appeal to. To be fair, I doubt we'll attract many new switchers from OS/2 now. I doubt there's anyone left.

can't be bothered to uncomment a line in a blacklist file.

What I am getting at is that to come to this conclusion requires an elaborate process of elimination that I suspect I could not complete myself, and I am not a newbie. So, if the issue here is removing old code that is not likely to be needed, then the real problem is not "what do we remove/disable" but "how to we give meaningful error messages that this is what has been done?" -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2/1/19 12:56 PM, Stefan Seyfried wrote:

I just tried out your very broad statement.

* Windows 10, latest patch level ("modern" in my perception). * USB Stick with GPT and ext4 and BTRFS partitions on it. * Plugged in * Windows offers to format it.

No driver autoloaded. No file system mounted.

I know that many young and inexperienced people believe the "MICROSOFT <3 LINUX" statement that the company now states, but it is not actually true and never was. The large amount of effort that Microsoft is putting into "Windows Services for Linux" shows this. It is just another instance of Microsoft's time-honoured and highly successful "embrace, extend and extinguish" strategy. Once this is understood, small niggling inconveniences for users of other OSes, which can be plausibly explained away, are a bonus. OTOH, Windows includes a huge number of drivers for a massive amount of hardware, which _benefits_ Windows users. You just need to work out "cui bono?" Who benefits? It helps MS if hardware works, even sub-optimally, because it helps MS users and customers. It also helps MS if interop with non-MS OSes silently fails *especially* if that means the other OSes must do more work. It doesn't help the customers, which shows where the company's focus _really_ lies.

And they are the ones that surely can and will find out how to add that one comment character to the config file to fix that. Even Felix will be able to solve that problem ;-)

That's true!

If all the docu-capable people would start writing wiki articles about this now, then once this is in an end-user facing distribution, a simple "openSUSE USB stick unknown file system" google search will lead them to the solution in no time.

Sadly there are quite a few other demands on our time. We're very short-staffed.

See the rest of this thread, we are already trying to work on that.

Great! Sincerely. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 01 Feb 2019 12:26:18 +0100, Liam Proven wrote:

I'm going to reorder this for clarity.

On 1/31/19 9:50 PM, Jim Henderson wrote:

...

If I need a file system that isn't installed,

How does a non-expert user know that this is the problem?

There's no such error message, AIUI.

AFAICT it merely says "unknown FS".

Well, as it happens, I ran into this recently. I got a new microSD card that was formatted exfat, and I got whatever the standard message was. My solution - STFW for what was needed to run exfat. Search the repos for anything exfat related, and install them. Then try again and look at the logs. And guess what - I got it working. Took all of about 15 minutes.

...

But I'd also be inclined to RTFM for information like that, too. What manual? How do you know what to look for?

I dunno, "hpfs not mounting"? Look under filesystems and make sure this change is documented? Ask the doc writers to include it. Include it in the release notes. There are lots of options.

...

my approach would be to look to see if it was included in the kernel package

How would they do that?

FWIW, as a Unix user for 31y and Linux user for 23y here, I'm not sure that *I* would know how to do that.

Well, I've only been using Linux since 1995, but I managed to figure it out with exfat. It isn't rocket science, and with proper documentation, we make it pretty clear for the dozen people who need hpfs because they still want to run OS/2 and Linux on the same box.

...

(which it sounds like it would be),

How do you know that? Do you think a non-expert would know that?

I think people should be able to figure it out, yes. Why do we assume that people are stupid or unable to ask questions when they run into problems? Isn't that what the community is for? Instead of looking for hypothetical problems for something that hasn't been implemented yet ("this isn't documented" - well, sure, it isn't NOW because it hasn't been implemented.)

...

and then to look at why it isn't auto-loading.

How would one get that far in the troubleshooting sequence to work out that this was the problem?

See my exfat example above.

...

That seems like common sense to me.

I can assure you, no, it is not! :-)

It's not common sense that if you have a problem that you should look at the log files? Then we need to educate users how to perform really basic troubleshooting. Because if they're having problems with this, IMNSHO, then they're having problems with things like how to log in and enter their passwords correctly. Using dmesg and other logging systems should be second nature. It's like looking at the event viewer in Windows when a service doesn't start. Yeah, my mother wouldn't know to do that - but she would know to ask someone who knows more, and that's what the community is for. But we're talking here about a change that affects more technical users - my mom isn't going to run a combined OS/2 and Linux box and need hpfs support. People who run that kind of combination are not causal users, they're people with a specific need and a specific skill set. We shouldn't treat them like idiots.

...

What doesn't seem like common sense to me is to load it on millions of installations where it isn't needed

Then all modern OSes must dismay you, because that is how they work: including tens of thousands of drivers that 99% of people will never need, just so that they are there and the software works for the 1% who need them.

Yes, thank you, Jeff clarified already how it works in practice. I generally don't worry about stuff like this because I'm not one of the dozen users who needs hpfs support. Like I said before, I don't have a horse in this race. It just seems silly to me to cater to a relatively small minority of users who have a specific need. We don't, to my knowledge, support parallel-port scanners out of the box either, do we? (Honestly don't know). But there may be more people who want that configuration than need hpfs or some of these other filesystems.

...

because a hundred (thousand, whatever small percentage use OS/2 in dual-boot configs with openSUSE)

Yes, I think it probably _is_ a very small proportion.

OTOH, *SUSE is one of the oldest distros, and OS/2 is one of the oldest PC OSes, dating back to 1988 IIRC. Hardcore OS/2 users are old-timers. They are the sort of market *SUSE might appeal to.

And those users, as I stated above, have some technical chops because they have a specific need for that combination. I mean really, we're not just talking OS/2 fans. We're talking OS/2 fans *who dual boot* and need to support hpfs in order to access data shared with a local OS/2 installation. That's a pretty small audience no matter how you slice it.

To be fair, I doubt we'll attract many new switchers from OS/2 now. I doubt there's anyone left.

...

can't be bothered to uncomment a line in a blacklist file.

What I am getting at is that to come to this conclusion requires an elaborate process of elimination that I suspect I could not complete myself, and I am not a newbie.

With respect, I don't see that as an "elaborate process of elimination". "Oh, I just installed OS/2 on this SUSE box" or "I just installed SUSE on this OS/2 box". "I need to mount this HPFS partition in Linux because <x>" "It didn't work. Why didn't it work?" <check logs> <check community> <check documentation> <check release notes> "Oh, it's blacklisted, and I can fix it by removing it from the blacklist file." Done. What other *possible* steps would need to be explored to get to that conclusion? I can't see this as an "elaborate process" by any stretch of the imagination. It's troubleshooting 101-level stuff.

So, if the issue here is removing old code that is not likely to be needed, then the real problem is not "what do we remove/disable" but "how to we give meaningful error messages that this is what has been done?"

Sure, meaningful error messages are helpful, and I'm in favor of that. But again, my issue having done this with exfat on Leap 15 didn't really need that, and I somehow managed to muddle through in about 15 minutes and get that microSD card mounted so I could copy some music files over to it in order to listen to them on my phone. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, 01 Feb 2019 15:13:11 -0500, Felix Miata wrote:

Jim Henderson composed on 2019-02-01 19:19 (UTC):

...

On Fri, 01 Feb 2019 12:26:18 +0100, Liam Proven wrote:

...

Well, I've only been using Linux since 1995, but I managed to figure it out with exfat. It isn't rocket science, and with proper documentation, we make it pretty clear for the dozen people who need hpfs because they still want to run OS/2 and Linux on the same box.

You have statistics to back up this "dozen", right? Stuff that has been just working for decades doesn't get much press.

If you've been reading my posts, Felix, you know that I'm referring to the photos from the Berlin conference that someone else referenced. It's a small number, nobody really doubts that, it seems. Let's not get hung up on the specifics number. Whether it's a dozen or 300, it's still a small number, and that's my point.

...

...

How do you know that? Do you think a non-expert would know that?

...

I think people should be able to figure it out, yes. Why do we assume that people are stupid or unable to ask questions when they run into problems? Isn't that what the community is for?

Remember for most people what computers are for? Saving time, and doing repetitive and difficult or otherwise impossible things. When something long working breaks, time saving morphs into time gobbling, not the least of which is Google's response to its bad responses feeding captchas instead of useful hits, the domino effect of one thing going wrong leading to multiple others before finding any light at the end of the tunnel, the kids stop screaming they're hungry, and sunrise begins before ever having gotten into bed.

Well, then, maybe every possible device should be enabled, just in case one person has a need to be able to connect it at some point, regardless of what we know or what the security implications are.

...

It just seems silly to me to cater to a relatively small minority of users who have a specific need.

Breaking what works because only some undefined population subset uses it. The voice of tyrannical majority speaking. If most don't need something, nobody needs it.

For every action, there is an equal and opposite reaction. 1686, Newton.

And leaving things in a system that add to the security footprint and places that can be exploited is a bad practice. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 05.02.19 um 18:32 schrieb Liam Proven:

Because, for the most part, people _are_ stupid.

You should not extrapolate from yourself! ;-) (SCNR, of course this is not meant seriously)

Problem #1: there are 2. One ending in G05 and one ending in G04. I can't find anything official or canonical with Google as to which package installs which GPUs. At least nVidia's website tells you that for its drivers -- but not for *SUSE's.

can't you just install both and the one matching the PCI ID of your card will be used? (Just guessing, I'm not going to touch NVidia with a 10 foot pole if not getting paid for it)

Because that's not how it works on Windows and that's all most PC users know.

Of course that's how I debug windows failures, too. Look at the event log viewer. The tools are just inferior.

Second reason: because we have blasted systemd now and as a result of that, half the most common basic logfiles have bally well disappeared and are now in some binary log format I don't know, hidden I don't know where and only viewable by a tool I don't know.

Well, digging through a zillion of log files in /var/log is certainly easier than "journalctl -b", which shows you all relevant logs from this boot (not the old, irrelevant ones) and even marks them with colors according to the severity level. I don't think I'd subscribe to your view of "easy". (and if you read up on the factory archives, probably nobody will think I'm a systemd apologist, but criticizing it just "because it's systemd" is certainly not making you look smart)

So when I started troubleshooting TW, a very early step was to install some package that disables systemd's binary logging and gives me actual logfiles again. *Then* I had to wait for various problems to occur again so that now I could actually look into plain text logfiles with ``less'' and find out what was going on.

This took extensive googling.

I still have the same email address as I did in 1991 and I have a system for generating unique passwords in my head, so I can work out what password I used, even 25 years later.

...

But I am very unusual.

Yes, but rather for being unable to find "journalctl" or "zypper in rsyslog" with a very quick google search ;-)

True story. 4y ago I interviewed with IBM for a midrange tech support job, 2nd/3rd level.

The first interview question was: on a Windows machine, where would you look for error logs?

This is a question they use to weed out _advanced_ techies from normal techies.

If you ever have talked to an IBM "advanced techie" then you know that the only thing advanced about this is the price tag. I wonder if anyone but IBM can pull such a thing ;-)

Other examples: you want to test a connection to another machine by IP address. What commands might you use?

Again: 2nd/3rd line support. I was some 46 years old at the time.

This is _not_ basic stuff any more.

Of course it is. Maybe not at IBM.

Stuff like this highlights problems that may be niche when the offending driver is $FOO but then 6 months later you find it also affects driver $BAR and some company is shipping a million devices a day that need driver $BAR.

Heartbleed.

Heartbleed was not exactly a "niche case". Anecdote: when colleagues had heard rumers about the new "heartbleed-WE_AR_ALL_GOING_TO_DIE!!!1!!!"-Bug, my first thought was "I don't believe it, it can't be that bad. Rogue memory read, ok, but how high is the probability that attackers will read interesting things?". Until the bug was published, I looked at the code, saw that these morons had implemented their own, inferior memory management and thus ensured that the interesting data (keys,...) was exactly at the same place everytime and easily accessible. Something that would not have happened with a modern system malloc() or such. And exactly because fringe code has such stupid bugs, we disable the drive-by-autoloading of random file systems.

This stuff really happens.

Don't leave edge cases because they're obscure or niche because it's a law of nature they'll come back and bite you.

Totalla agreed, don't leave the attack surface open. Blacklist fringe filesystems NOW! :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 05.02.19 um 21:43 schrieb Michal Suchánek:

On Tue, 5 Feb 2019 18:57:31 +0100 Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:

...

Am 05.02.19 um 18:32 schrieb Liam Proven:

...

...

Second reason: because we have blasted systemd now and as a result of that, half the most common basic logfiles have bally well disappeared and are now in some binary log format I don't know, hidden I don't know where and only viewable by a tool I don't know.

Well, digging through a zillion of log files in /var/log is certainly You can even grep those zillion files. And it does not take hours to extract them from the journal database in case you have moderately busy system. But that's not a problem that happens on personal notebooks such as Lennart's or yours, sure.

A "moderately busy server" can still easily log to syslog in addition to the journal. All my machines do. And I am one of the customers that created Service requests about supportconfig taking 8 hours(!) to dump the journal from the ramdisk(!!) on SLES12, and I really hate how some of it is (or was) implemented, because I looked at the code early to find out why it worked so badly on rotating rust. So I'm in no way suggesting that the journal is a perfect solution. But Liam's narrative that "it's totally impossible to debug a system using the journal is just fake news. (And he is not running a busy server, or he would not be complaining about NVidia drivers on TW).

...

easier than "journalctl -b", which shows you all relevant logs from this boot (not the old, irrelevant ones) It even shreds the old, irrelevant ones for you so when something stops working you cannot compare with with logs from the time it did work. and even marks them with colors according to the severity level. systemd is generally not a bad idea. The documentation sucks, however. And the implementation comes with some odd defaults very flawed pieces, such as journald.

journald has an interface different from anything else you have to learn just to view your logs on systemd diseased system.

Certainly. But it's not impossible to use, and you do not need hours of fruitless googling to find out how to use it.

That would be excusable if the tool was good but it brings no real advantage and really poor performance.

Personally, I find "journalctl -b" , "journalctl -b -1" a really useful feature, much better than searching for the right "rsyslog restart" mark in /var/log/messages.

Maybe you need to do more research before you bash something

The only thing I'm maybe bashing is the "I am not going to learn new things, but want to run the latest rolling release" attitude shown by some participiants of this list. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Feb 06, 2019 at 09:55:38AM +0100, Andreas Schwab wrote:

On Feb 06 2019, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:

...

Personally, I find "journalctl -b" , "journalctl -b -1" a really useful feature, much better than searching for the right "rsyslog restart" mark in /var/log/messages.

And it is quite easy to view the log of a single service with `journalctl -b -u foo'.

I too like journalctl's viewing features. However the default not too store previous logs has bitten me twice in recent months, on different systems. I think 'Storage=auto' should not be the openSUSE default. Swapping tales-of-woe with a Mint using colleague, he too had been baffled by missing logs, so I assume persistence is an upstream thing. Kepner-Tregoe built a business around "the trouble is..., the trouble is not...". Holding "working" logs can be invaluable when trying to troubleshoot, easily worth the meagre cost of storage and trivial overhead of log segmentation/rotation. Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2/6/19 8:24 AM, Stefan Seyfried wrote:

But Liam's narrative that "it's totally impossible to debug a system using the journal is just fake news.

That is not even _remotely_ related to what I said. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2/6/19 8:38 AM, Liam Proven wrote:

On 2/5/19 6:57 PM, Stefan Seyfried wrote:

...

Am 05.02.19 um 18:32 schrieb Liam Proven:

...

Because, for the most part, people _are_ stupid.

You should not extrapolate from yourself! ;-)

(SCNR, of course this is not meant seriously)

:-D

No problems at all.

...

can't you just install both and the one matching the PCI ID of your card will be used?

I confess I have not tried, but previous experience with previous nVidia drivers on other distros suggests that no, this won't work. The driver only supports one instance at a time.

...

(Just guessing, I'm not going to touch NVidia with a 10 foot pole if not getting paid for it)

*Shrug* It's the machine SUSE gave me.

...

...

Because that's not how it works on Windows and that's all most PC users know.

Of course that's how I debug windows failures, too. Look at the event log viewer. The tools are just inferior.

Agreed.

But most Windows users _don't_ debug failures. At all. They might pay someone else to.

...

Well, digging through a zillion of log files in /var/log is certainly easier than "journalctl -b", which shows you all relevant logs from this boot (not the old, irrelevant ones) and even marks them with colors according to the severity level.

I don't think I'd subscribe to your view of "easy".

I use the traditional Unix methods that I know and have used for ~3 decades. I do not run servers for a living, or develop software, or build distros. If the methods have changed and don't work, my first response, generally, is not "excellent, let's learn something new!" My first response is more like to be "can I put the old method back?"

I am not arguing that this is the best attitude, but I bet it's a fairly common one.

...

...

So when I started troubleshooting TW, a very early step was to install some package that disables systemd's binary logging and gives me actual logfiles again. *Then* I had to wait for various problems to occur again so that now I could actually look into plain text logfiles with ``less'' and find out what was going on.

This took extensive googling. [...]

...

...

...

But I am very unusual.

Yes, but rather for being unable to find "journalctl" or "zypper in rsyslog" with a very quick google search ;-)

Hang on. In _the previous paragraph_ I said that this is exactly what I did.

Come on, be fair.

...

...

True story. 4y ago I interviewed with IBM for a midrange tech support job, 2nd/3rd level.

The first interview question was: on a Windows machine, where would you look for error logs?

This is a question they use to weed out _advanced_ techies from normal techies.

If you ever have talked to an IBM "advanced techie" then you know that the only thing advanced about this is the price tag. I wonder if anyone but IBM can pull such a thing ;-)

*LOL*

That may be so.

My point is, it's not _basic_ troubleshooting knowledge. Yes, it probably should be, but it isn't.

...

Heartbleed was not exactly a "niche case". Anecdote: when colleagues had heard rumers about the new "heartbleed-WE_AR_ALL_GOING_TO_DIE!!!1!!!"-Bug, my first thought was "I don't believe it, it can't be that bad. Rogue memory read, ok, but how high is the probability that attackers will read interesting things?". Until the bug was published, I looked at the code, saw that these morons had implemented their own, inferior memory management and thus ensured that the interesting data (keys,...) was exactly at the same place everytime and easily accessible. Something that would not have happened with a modern system malloc() or such.

There are different ways to address this.

One, which in my personal non-day-job life I quite favour, is to be interested in OSes which contain no C code at all and look forward to the days when the entire C and Unix family is ancient history.

Another extreme is to trust nothing and be very paranoid. But then, OpenBSD is, and it still happened.

It is simply that turning stuff off instead of fixing it seems short-sighted to me.

It's a simple cost-benefit analysis. Developer time (even if it's volunteer) isn't free. If you want to invest your personal time in auditing and improving every file system that Linux supports, that's certainly your prerogative. As those file systems are improved, we can discuss removing them from the blacklist. -Jeff -- Jeff Mahoney SUSE Labs

On Wed, Feb 06, 2019 at 05:48:24PM +0100, Liam Proven wrote:

On 2/6/19 5:05 PM, Jeff Mahoney wrote:

...

It's a simple cost-benefit analysis. Developer time (even if it's volunteer) isn't free. If you want to invest your personal time in auditing and improving every file system that Linux supports, that's certainly your prerogative. As those file systems are improved, we can discuss removing them from the blacklist.

But that's not how it works.

I'm afraid that how it works is:

"I tried $DISTRO-1 but it didn't work with $DISTRO-2 and $OTHER-OS, so I switched to $DISTRO-3 because it just worked."

And that least to

"Yeah, $DISTRO-1 doesn't work as well with other hardware and doesn't dual-boot well, so don't waste your time on it."

I'm not saying this is right or good. It's just how it is.

Which inevitably brings us back to the question if our primary goal is (or should be) having as many users as possible, whatever it takes. As I already explained, my answer is negative because the type of thinking you just described is typical for users who would consume quite a lot of resources with little chance to ever give something back (except for having many users which is of questionable value). Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, 06 Feb 2019 17:48:24 +0100, Liam Proven wrote:

On 2/6/19 5:05 PM, Jeff Mahoney wrote:

...

It's a simple cost-benefit analysis. Developer time (even if it's volunteer) isn't free. If you want to invest your personal time in auditing and improving every file system that Linux supports, that's certainly your prerogative. As those file systems are improved, we can discuss removing them from the blacklist.

But that's not how it works.

I'm afraid that how it works is:

"I tried $DISTRO-1 but it didn't work with $DISTRO-2 and $OTHER-OS, so I switched to $DISTRO-3 because it just worked."

Until the headline "all Linux systems using [filesystem that should have been blacklisted] exposed to fatal security flaw" shows up. I'd rather be secure by default. You don't prevent security exploits from being used by saying "yeah, whatever, make it easy and don't give a damn about security until it's a problem" - because at the point the problem is reported, it's too late. Like I said earlier, if you're offering to step up and do proper maintenance on these niche filesystems, that's great. They need it. But if you're not, then don't make my systems less secure because it's too inconvenient for you to uncomment a driver you need in a blacklist file on the systems you specifically need the feature on. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Feb 05, 2019 at 06:32:17PM +0100, Liam Proven wrote:

I mean, as an example, I got a new PC recently at work. It has nVidia graphics. Getting the nVidia driver working on Tumbleweed was pretty horrible. After a lot of experimentation, I ended up downloading the file direct from nVidia US and installing it, because unlike anything in the repos, AFAICT, this does stuff like blacklisting the "nouveau" driver for you.

Then I discovered that every time TW gets a new kernel, X.11 falls over. I installed DKMS but it's not working. ... Drivers are _hard_, stuff like blacklisting stuff is harder, and troubleshooting it is not easy.

From your e-mails, both here and in the recent discussion about bogus Phoronix benchmarks, it seems that you believe the goal of openSUSE is (or at least should be) attracting as many users as possible which mostly means adapting the distribution to meet the expectations of

I also got a machine with an nvidia card but I took a different approach: nvidia, by their attitude towards linux drivers, makes it absolutely clear they don't want me to use their products. So I picked some radeon card from the cupboard and replaced the nvidia. Eight years later, I'm absolutely sure I chose the right solution which saved me a lot of time and a lot of frustration. No problems with finding a driver, no breakage after each update, I can even run Kernel:HEAD snapshots on the machine. Sometimes the constraints exist only as long as you refuse to think out of the box. people who don't want to think, learn or work. I don't agree with such goal because it would mean way too many sacrifices which would make the distribution less attractive for me. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Maybe in the enterprise world it makes sense to try to protect your computers from bad flash drives by removing support for things, but I'm sure that's an idea that's opposed to the way most people that work with open or free software think, at least from where I'm standing, even if it has any real effectiveness as a defence against bad flash drives. I say it without looking at the list: please get all those file systems back to Tumbleweed. I lost half an hour last night when I soft-bricked my phone to fastboot and suddenly my machine that did mkfs e2fs the other day couldn't mount the SD card with data I needed to repair the phone. But I now realize maybe this wasn't really that of a boomer since now I can present you with this cautionary tale. This is why you shouldn't just break any one of those systems that were for a long time supported on Tumbleweed and are probably in use somewhere, we can never now how often, and so we can't weight the potential damage of breaking it. I felt sad at the time because I realized that feature was present some time before and was removed without any consent on my part and without a package removal that would make it explicit. Also it would take me a considerable amount of time, even not being a novice Linux user, I've just been busy and never saw any changelogs or notices or more sadly this thread to find out which line I'd have to comment out, and even if it were as easy as a click hidden away somewhere, most users would never get to read this thread or to google it and would probably just think Tumbleweed doesn't support those filesystems any more and move on. Please stop assuming users are experts and don't make more difficult software for those that already don't know how to use it, just because you say it's not that much of them. Remember the user base of OpenSuSE is nothing alike SLES's. Please move to the "whitelist" alike approach by default on SLES and leave Tumbleweed with this basic feature for working with any software system, even with those you don't use, even if you're not fond of it or it's old. At least don't do it by default, leave this kind of feature disabling as security measure optional. And of course, making people unable to mount as root as a security measure is just not ok. I'd be glad to see it working again. Not to mention that making bad jokes about other users choices or knowledge in a mailing list should really be taken seriously. How come you behave like children in public like this, just because it's "the internet"? "The community" is not an excuse for your bad choices. If you say those things and think you know you user base, then you don't. Please be less reckless in the future guys! In that and in not just breaking things. With that said, with less of that I'll probably keep using your software for another ten years. Best regards, Raphael On Tue, 5 Feb 2019 at 20:14, Richard Brown <RBrownCCB@opensuse.org> wrote:

On Tue, 5 Feb 2019 at 22:29, Michal Kubecek <mkubecek@suse.cz> wrote:

...

On Tue, Feb 05, 2019 at 06:32:17PM +0100, Liam Proven wrote:

...

I mean, as an example, I got a new PC recently at work. It has nVidia graphics. Getting the nVidia driver working on Tumbleweed was pretty horrible. After a lot of experimentation, I ended up downloading the file direct from nVidia US and installing it, because unlike anything in the repos, AFAICT, this does stuff like blacklisting the "nouveau" driver for you.

Then I discovered that every time TW gets a new kernel, X.11 falls over. I installed DKMS but it's not working. ... Drivers are _hard_, stuff like blacklisting stuff is harder, and troubleshooting it is not easy.

I also got a machine with an nvidia card but I took a different approach: nvidia, by their attitude towards linux drivers, makes it absolutely clear they don't want me to use their products. So I picked some radeon card from the cupboard and replaced the nvidia. Eight years later, I'm absolutely sure I chose the right solution which saved me a lot of time and a lot of frustration. No problems with finding a driver, no breakage after each update, I can even run Kernel:HEAD snapshots on the machine.

Sometimes the constraints exist only as long as you refuse to think out of the box.

From your e-mails, both here and in the recent discussion about bogus Phoronix benchmarks, it seems that you believe the goal of openSUSE is (or at least should be) attracting as many users as possible which mostly means adapting the distribution to meet the expectations of people who don't want to think, learn or work. I don't agree with such goal because it would mean way too many sacrifices which would make the distribution less attractive for me.

Michal Kubecek

I wholeheartedly agree with Michal

openSUSE is a community project, therefore one of our first concerns should always remain ensuring our Project is self-sustaining.

The first, and I believe best, step to achieving that is remembering the first lesson of "The Cathedral and the Bazaar" -

"Every good work of software starts by scratching a developer's personal itch."

openSUSE needs to be producing stuff by the openSUSE Project, for the openSUSE Project first and foremost. Outreach for new users should be driven by people personally motivated to address those area's we're reaching into (therefore, still sticking to the first rule). For those who believe grabbing new users is really really important, I'm afraid that means accepting that some people like Michal exist and will not share your vision. You wouldn't like it if someone tried to force you to do something you don't appreciate. Be careful not to act in that way to others.

Forcing people to chase after dreams they don't share just risks contributors to openSUSE drowning under poor motivation, burn out, and at best will produce dispassionate solutions to poorly understood problems remotely observed.

Let's keep the project focused on those things we personally care about, and try our best to avoid chasing unicorns. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I have accurately lost this feature and there's no reprisal you can make to undermine that. Please try to contribute in here instead of demining other user's posts. On Tue, 5 Feb 2019 at 22:55, Jan Engelhardt <jengelh@inai.de> wrote:

On Wednesday 2019-02-06 00:51, Raphael Lydia Bertoche wrote:

...

I say it without looking at the list:

...

suddenly my machine that did mkfs e2fs the other day couldn't mount the SD card with data I needed to repair the phone.

e2/e3/e4 is built into the kernel image and blacklisting would have no effect. (It's also too important a fstype to be put on a blacklist.)

So please, stop complaining without verifying that what you write is accurate.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

I replied to the old thread, so here I say again, you were right about e2fs being enabled, in fact I had problem with f2fs. Just don't be a moron and say to people to shut up until they're talking accurately. On Tue, 5 Feb 2019 at 23:32, Raphael Lydia Bertoche <bertocheraphael@gmail.com> wrote:

I meant diminish other user's posts

On Tue, 5 Feb 2019 at 23:31, Raphael Lydia Bertoche <bertocheraphael@gmail.com> wrote:

...

I have accurately lost this feature and there's no reprisal you can make to undermine that.

Please try to contribute in here instead of demining other user's posts.

On Tue, 5 Feb 2019 at 22:55, Jan Engelhardt <jengelh@inai.de> wrote:

...

On Wednesday 2019-02-06 00:51, Raphael Lydia Bertoche wrote:

...

I say it without looking at the list:

...

suddenly my machine that did mkfs e2fs the other day couldn't mount the SD card with data I needed to repair the phone.

e2/e3/e4 is built into the kernel image and blacklisting would have no effect. (It's also too important a fstype to be put on a blacklist.)

So please, stop complaining without verifying that what you write is accurate.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dear Michal K, every time anyone tries to silence someone else with an argument of authority, especially if that argument is being the holder of truth, I'll see that person as a moron. Sorry to you all if it didn't seem like well justified rebound, maybe I did overreact. e2fs was only in the progs package name in my vocabulary, never the file system itself, so here are all those mistakes. Michal S, I don't see disabling a feature that's been available for a long time as "not removing support for it" unless you did something as easy to unlock as what browsers do to prevent you from accessing sites with old certificates, that doesn't stop normal users from consciously overriding it. If it's disabled for most people, then for most people support is not present anymore. I'm sorry we disagree in that. Also the thread says "disable by default" and not "disable optionally" or something that doesn't break mounting as root. When I tried it just failed. About the RTFM part, mostly because of YaST I regard openSUSE as one of the few distros that really anyone can use. In my view it's way better than Ubuntu in that, except that more people heard about the latter. I only meant to express that I hope it remains a very user-friendly distro. If that doesn't hold then my hope is lost. Manuals are things that only people that are truly versed in Linux will ever be able to read and understand, and in fact will ever open it as well. I'll say it again: please don't assume that just because it's system infrastructure that it's not software for people that won't ever read any software manual. Please remember that most people's experiences with software help or manuals is nothing alike what we have with man, info and everything. Not because open source programmers are geniuses and corporate people aren't, but because manpages were mostly written for and by programmers, and that is also why so many tech people from other areas that aren't versed in that particular jargon really can't read a manpage. I myself usually think and reread for dozens of minutes to really dig each argument in manpages for standard c functions. I'm happy nobody ever told me to start learning C from these sources, so I ask of you to rethink about that part where people should learn SUSE from manpages at the first time they can't mount a drive. Don't just say RTFM for newbies. Please keep teaching Linux in openSUSE fun! I see I'm not the only one that enjoys it here. And for those questioning the utility of new users: a system with no users is dead, so you just must keep at least a minimum throughput of people learning it over time. It's not optional, it's need. With that many distro options just don't take it for granted, especially in the long run. Please someone clarify me: How preventing users from mounting as root from where they could gain no further escalation could be more damaging than a myriad of other mistaken or bad informed commands when ran as root? I don't understand why can't this blacklist affect only auto mount or other mount commands issued from a GUI application ran by the a normal user. Is it just that hard to do it where it matters most, or blocking root access is really intended here? I don't intend no critic here, I'm just not seeing the whole picture that you're arguing really. If someone has sudo or my root password I really can't avoid that they are able to jeopardize the system even without any flash drive. Is it really intended to prevent wilful people that really should be able to mount it from doing so? I guess it's getting a nicer error message or addendum, but what about an analog for GUI actions, is it possible? At least something that gets propagated over file manager apps that come in the DVD. I'm sorry if it's already mentioned, the thread has gone way to long and here I am making it worse. Also, if I am not wrong this time, f2fs is the only officially supported way you can install apps as opposed to only some app data to an external SD card in Android. Some phones since version 6.0 if I recall correctly have an easy "transfer app" option that does fsck on the external drive. Can it be really that obscure even if it's so easy to make in a considerable amount of Android devices? But then maybe that doesn't matter, does it? Best regards and have a good day, Raphael -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 5 Feb 2019 21:51:13 -0200 Raphael Lydia Bertoche <bertocheraphael@gmail.com> wrote:

Maybe in the enterprise world it makes sense to try to protect your computers from bad flash drives by removing support for things, but

Did you read this thread? It is about closing the security hole ^without* removing support for those filesystems.

I'm sure that's an idea that's opposed to the way most people that work with open or free software think, at least from where I'm standing, even if it has any real effectiveness as a defence against bad flash drives.

It makes sense anywhere. The filesystem has known security vulnerabilities and in absence of somebody willing to fix it there is a gaping security hole.

I say it without looking at the list: please get all those file systems back to Tumbleweed. I lost half an hour last night when I soft-bricked my phone to fastboot and suddenly my machine that did mkfs e2fs the other day couldn't mount the SD card with data I needed to repair the phone. But I now realize maybe this wasn't really that of a boomer since now I can present you with this cautionary tale. This is why you shouldn't just break any one of those systems that were for a long time supported on Tumbleweed and are probably in use somewhere, we can never now how often, and so we can't weight the potential damage of breaking it.

I felt sad at the time because I realized that feature was present some time before and was removed without any consent on my part and without a package removal that would make it explicit.

Also it would take me a considerable amount of time, even not being a novice Linux user, I've just been busy and never saw any changelogs or notices or more sadly this thread to find out which line I'd have to comment out, and even if it were as easy as a click hidden away somewhere, most users would never get to read this thread or to google it and would probably just think Tumbleweed doesn't support those filesystems any more and move on. Please stop assuming users are experts and don't make more difficult software for those that already don't know how to use it, just because you say it's not that much of them. Remember the user base of OpenSuSE is nothing alike SLES's.

That's why an update to mount documentation is proposed. If you cannot RTFM all hope is lost. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, 6 Feb 2019 11:47:10 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:

On 06/02/2019 08.59, Michal Suchánek wrote:

...

That's why an update to mount documentation is proposed. If you cannot RTFM all hope is lost.

Maybe delay the removal till all the changes, including documentation, is in place? Implement all the changes in a single update?

As Tumbleweed is released in snapshots it will probably happen all at once except for the f2fs which was disabled earlier in response to security incident. When that happens you can un-blacklist it again and access your phone storage or whatever. Thanks Michal

On Wednesday 2019-02-06 17:46, Liam Proven wrote:

On 2/5/19 10:29 PM, Michal Kubecek wrote:

...

From your e-mails, both here and in the recent discussion about bogus Phoronix benchmarks, it seems that you believe the goal of openSUSE is (or at least should be) attracting as many users as possible which mostly means adapting the distribution to meet the expectations of people who don't want to think, learn or work.

That is nearly as inaccurate a representation of what I am saying as Stefan's.

I am not saying that at all.

What I am saying is this:

* The Linux market is very competitive.

The openSUSE project is not driven by capitalism and does not have to generate revenue (in fact, it's pretty much sponsored all the way). SLES is a playing field with different competitors - and stakeholders. Let that group do what they particularly need for their model.

If a company wants to survive, it has to attract new customers. Capitalism mandates growth.

(Not necessarily... $company could go for a defacto monopoly.) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 2019-02-06 19:18, Daniele wrote:

Il 06/02/19 18:43, Jan Engelhardt ha scritto:

...

On Wednesday 2019-02-06 17:46, Liam Proven wrote:

...

On 2/5/19 10:29 PM, Michal Kubecek wrote:

...

From your e-mails, both here and in the recent discussion about bogus Phoronix benchmarks, it seems that you believe the goal of openSUSE is (or at least should be) attracting as many users as possible which mostly means adapting the distribution to meet the expectations of people who don't want to think, learn or work.

That is nearly as inaccurate a representation of what I am saying as Stefan's.

I am not saying that at all.

What I am saying is this:

* The Linux market is very competitive.

The openSUSE project is not driven by capitalism and does not have to generate revenue (in fact, it's pretty much sponsored all the way).

YEp but usually: more users, more attention, more diffusion -> More sponsor -> more resources.

In case it still has not permeated across to you: many free projects are basically ego trips. Someone had an idea, and implemented it. If a followership accrues, that is by accident. The least objective of all is to be an attention seeker. Except if that is your main goal (at which point something else goes down the drain). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Feb 06, 2019 at 05:46:18PM +0100, Liam Proven wrote:

On 2/5/19 10:29 PM, Michal Kubecek wrote:

...

From your e-mails, both here and in the recent discussion about bogus Phoronix benchmarks, it seems that you believe the goal of openSUSE is (or at least should be) attracting as many users as possible which mostly means adapting the distribution to meet the expectations of people who don't want to think, learn or work. I don't agree with such goal because it would mean way too many sacrifices which would make the distribution less attractive for me.

That is nearly as inaccurate a representation of what I am saying as Stefan's.

I am not saying that at all.

What I am saying is this:

* The Linux market is very competitive. Different distros have different strengths and weaknesses. It is fatally short-sighted to ignore what other distros and other companies are doing, for any reason, whether the reason is "Not Invented Here" syndrome, or because $DISTRO is not seen as a real competitor, or because of tradition.

If a company wants to survive, it has to attract new customers. Capitalism mandates growth.

I'm afraid we don't agree on the premises so there is little sense for me to comment on the conclusions. First, SLE is in the "Linux market", openSUSE is not. So the rules of market or capitalism do not apply to it directly. Second, even for SUSE/SLE (or any other of our products), attracting as many customers as possible is not necessarily the right goal. We could possibly get a lot of customers by combination of low price, very long support contract lengths, very short response times etc. We would quite likely lose some sane customers who would be reasonable enough to realize that under these conditions we would be out of business very soon. And they would be right. Even for a commercial company, it's not just about attracting the customers. We need to attract them in a way which will leave us with reasonable profit after subtracting the costs. And we have a lot of people whose job is to weigh carefully how to do that.

Ubuntu decided on a fairly simple play. Pick a free distro with, at the time, the best packaging tool -- i.e. Debian, circa 2002-2003 or so -- and put a really nice easy desktop on it, with a complete set of integrated apps, and an easy installation program, and give it away for nothing. This was so the sponsor could give something back to the FOSS community that made him a billionaire (or near enough).

This has made Ubuntu the #1 end-user desktop distro.

Many people argue with this and it's very hard to prove, but in terms of mindshare, press coverage, etc., I think it's obviously the case.

Now, a decade and a half later, that means that there are hundreds of thousands of Linux folk who learned on Ubuntu first and know it best, and because of that, Ubuntu is what they choose to deploy on their servers and in their VMs and clouds.

According to https://www.zdnet.com/article/inside-ubuntus-financials/ there is 14 times more Ubuntu instances than RHEL in AWS. And yet, when you look at the financial results, Canonical is not exactly thriving - and even less so compared to Red Hat. Sure, Red Hat is not only RHEL but I'm pretty sure even the part of Red Hat's profit coming from RHEL would be way bigger than Canonical's $2M in 2017 or $6M in 2018, not to mention the continuous seven years of loss before that. No company could afford doing business the way Canonical used to until ~2 years ago without also having a "generous uncle". So please don't use Ubuntu as an example of how to do things if you want to talk about "market" and "capitalism" at the same time. It doesn't have anything in common. And the same as what I wrote above above having to take the costs into account actually holds for openSUSE. We have limited resources and we have to weigh carefully what we use them for. Focusing on the kind of users you want to attract (unwiling to think about problems, unwilling to learn things, unwilling to invest their time and energy) means getting a lot of users who will need a lot of help even with the basic tasks. That means that skilled users will either spend a lot of time helping them or (more likely) will simply stop helping. Or even worse, when they see that we rather compromise their security just to make life of the lazy ones easier, that we make the distribution less usable just to rank better in bogus Phoronix "benchmarks", they may leave completely. Am I imagining things? I don't think so. Which distribution is the most popular? Ubuntu. Did you notice that when you google for a solution of some nontrivial problem, almost always one of the first results least to launchpad.net - but that while there is usually a lot of comments, it's quite rare to find anything useful in them? OpenSUSE is certainly not one of the largest distributions, measured by number of users. But I dare to say that we might have achieved an interesting ratio of skilled users and users willing to contribute, whether it's bugfixing, packaging or testing and meaningful reporting. There is a long running joke that the reason why openSUSE has no community is that whenever someone becomes really active in openSUSE community, he sooner or later ends up as a SUSE employee. Sure, it's just a joke but as with many others, there is some deep truth hidden in it. Do we want to risk these users just to attract a lot of passive ones or even pure consuments of resources? I don't.

To thrive, Linux distros have to attract users from other Linux distros.

I believe this narrow focus on attracting new users or customers is one of the big problems of our society. My term for the problem is "society ADHD". It's the narrow minded focus on attracting new users/customers leading to completely ignoring those one already has and their need and preferences. This leads to focus on these new users - and even more so potential users - being able to use the device, program or distribution without learning anything and without reading boring manuals. What do distribution "reviews" look like? The "reviewer" goes through the installation, makes a few screenshots, boots, takes few more screenshots, logs into KDE/Gnome, starts few well known applications and takes some more screenshots. The more responsible ones keep it running for few hours and maybe even try to simulate some real life activity. What does such "review" tell you about how well is the distribution serve an everyday user after few monts when he learned about its quirks and cool features? Nothing - exactly as those undercooked Phoronix benchmarks, exactly as superficial and meaningless. In early 90's (!) I read an article where the author came with a fitting name for this approach to device design and software user interface: "unuser friendly". The idea is that instead of being "user friendly", i.e. friendly to people who actually _use_ them, design is tailored to being friendly to people who know nothing (and don't want to learn anything) about them, i.e people not using them... "unusers" ("nonusers" would sound better but that would spoil the word play with "unuser friendly" vs. "user unfriendly"). The real problem is that it almost always comes at the expense to being less friendly (or even unfriendly) to actual users. And he came with that in ~1991; I wonder what would he say about today's consumer electronics and software (he died in 2001). If I'm going to use a device (TV, photo camera, phone, car) for ten years, I'm certainly willing to sacrifice few hours to learn to use it efficiently but I would be frustrated to have a frequently used function hidden somewhere in menu just because that way it's easier to find for someone who knows nothing about the device (and with no option to make it more efficient to me). It's the same with openSUSE: if we want to make it attractive to "unusers", it's hardly possible without making it less attractive to actual users. On one hand, you keep talking about people who learn on some distribution and then use the same (or its bigger brother) when they become admins. On the other, you propose changes which directly target at users unwilling to learn _anything_. Even if I forget that in big companies it's rarely admins who make such decisions, I fail to see how are the people who are completely unwilling to learn anything about the system are going to become admins. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday, 6 February 2019 23:38 Carlos E. R. wrote:

Do you know that I came to install SuSE because of a good review on the summer of 1998?

I initially installed something else. Debian? Redhat? I don't remember, but I understood nothing. Then a magazine published a review of several distros, a comparison. It said that "SuSE professional" was the easiest one of the lot. And another magazine summer special included 5.3 on two CDs.

So I went for it and never looked back :-)

Good reviews are important to newbies.

Not a contradiction. Information source being useless as a source of actually useful information doesn't prevent it to be loved by a lot of people and taken seriously by them. Maybe exactly the opposite... Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday, 6 February 2019 23:21 Carlos E. R. wrote:

Some time not very long ago, I attended a long training course. Most of it was about Windows Server administration, but we dedicated some time to Linux as well. Guess what? They all installed Ubuntu. I insisted and installed openSUSE. I succeeded because of who I am, but I had to do more effort than the rest because I had to investigate more and change the procedures. The procedures for whatever, all assumed Ubuntu. All the instructions were for Ubuntu. I managed to do everything, on my own, but it was harder and longer (maybe days longer)... As I say, I was the single one in the whole class not using Ubuntu.

Sounds to me as if, as a result, you learned more about Linux than anyone else in that training. :-) I was running linux trainings myself for nine years (2002-2011). I was using SuSE Linux / openSUSE on the machines, mostly because (1) that was what I was using myself and (2) AutoYaST (which saved me a lot of work when preparing the lab) but I tried to make the trainings as distribution independent as possible. Sometimes there were people who were trying things on their laptops in parallel. Few times there was someone at the beginning who was surprised or even disappointed about using SuSE Linux (openSUSE) rather than current distribution of fashion but I don't remember anyone complaining about it in the feedback form _after_ the training. Things can be done in different ways and the most common is not necessarily the best. If I believed what most people are using is automatically the best, I would have probably never started playing with Linux at all, 24 years ago.

The documentation of services my country administration provides, sometimes contemplate Linux, but when they do, it is Ubuntu what they use. Their docs give examples using Ubuntu. Thus when a month ago I tried to use my country ID card electronic identification system on openSUSE, I failed. All the instructions are for Ubuntu. No wiki page here.

I had similar experience recently with Ubiquiti Unifi Controller software which is provided for Windows, Mac and Ubuntu. I also lost patience trying to make the Ubuntu package work on openSUSE so I installed it on RPi3 with raspbian first and eventually bought their dedicated "hardware" controller (which is more up-to-date and better maintained anyway). But I (1) don't blame openSUSE and (2) don't see the experience as a reason to switch openSUSE to debian style package management and Ubuntu library naming scheme and filesystem layout. There will be always people whose conclusion from such experience would be "see, openSUSE is crap, nothing works there" but as I said multiple times, I'm not convinced this is the type of potential users we should focus on. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2/9/19 7:45 PM, Jim Henderson wrote:

I prefer not to start with the assumption that people are stupid. But what do I know, I've only been in online communities for about 30 years. m-/

Interesting. I got online in 1985 myself. My conclusion from the experience, and from just over half a century of life, is that most humans are very *very* stupid. At best, they are stupid outside of their specific area(s) of expertise -- if they have any. YMMV. I don't know what "m-/" means.

Determining that something is listed in a file as blacklisted is *not* harder.

Can I ask you for just one thing? Try to hold in mind that stuff that you find easy may be stuff that other people find hard, and /vice versa./

Linux is not Windows. I think anyone who uses Linux knows that.

You do? Gosh.

But I suspect that's not the case; you want usability for your niche use- cases at the expense of the broader community's system security.

Thanks, but no thanks.

OK. Yes, I disagree, but I am getting a strong impression from this thread that what I want out of my own computers' OS is not what *SUSE people want from theirs. So, fine. I accept that and will let it go. Life's too short. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2/11/19 5:31 PM, Jim Henderson wrote:

...

I don't know what "m-/" means.

Facepalm.

Aha! Useful.

Like I said, I've only been doing online community support for about 30 years. I have found that people can be taught, and if they have questions, they'll ask them. That's part of what the community is for and what it does.

There are definitely people like that, yes. Not many of them -- a small minority of computer users, I'd say. For instance, a decade or so ago, I wrote a series of getting-started-with-Linux articles for the Register, and included some very simple commands to enable some additional repositories and add in packages for video playback and so on. In the comments, I was lambasted for this. "If you have to type anything, it's too hard. Ordinary users won't do that." Etc. Other commentators pointed out that with text commands, you could cut-and-paste them, and that meant they'd be error-free. Long descriptions of what to click can't be copied-and-pasted, and that means people will get stuff wrong. Doesn't matter. I still alienated people. This is why there now 14× as many Ubuntu Server instances on AWS than Red Hat ones. I wonder how many there are of *SUSE compared to Red Hat? Yes, there are people who will, given guidance, learn. But everyone is a beginner at some point, and making things as easy as possible for beginners -- which is what Ubuntu set out to do -- is what wins you users. Secondly, there is a separate problem. If they use computers, people use desktops and laptops. Most of those use Windows. That is, by default, what people know. The problem is that Windows users know nothing about any other OS, but they don't know that. They think that they're skilled expert computer users. So if there are obstacles in their path, they will fall over, and they will unhesitatingly blame the product, not their lack of knowledge. The *only* way to win over such people is to ensure that there are no problems in their path. That everything works as they expect. That means giving them a Windows-like desktop and making sure everything just works out of the box. That's just how it is, IMHO and in my experience. But yours appears to be different. So I think it's time to stop trying to persuade anyone to my side. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 2019-02-11 20:01, Jim Henderson wrote:

On Mon, 11 Feb 2019 19:41:45 +0100, Liam Proven wrote:

...

The *only* way to win over such people is to ensure that there are no problems in their path. That everything works as they expect.

Most people want secure systems that are easy to use.

Maybe we should ship with Xorg permissions open to the world. Because if I'm running an application remotely from another system, having to type 'xhost +' or to enable permissions is "too hard".

Tech note: Most people should be running an SSO-style solution. ssh, su, etc. forward appropriate key material through environment variables and the like just by logging in, making the use of xhost wholly unnecessary. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 2019-02-11 20:25, Jim Henderson wrote:

...

...

Maybe we should ship with Xorg permissions open to the world. Because if I'm running an application remotely from another system, having to type 'xhost +' or to enable permissions is "too hard".

Tech note:

Most people should be running an SSO-style solution. ssh, su, etc. forward appropriate key material through environment variables and the like just by logging in, making the use of xhost wholly unnecessary.

Too inconvenient, according to some. After all, if you're using ssh with public keys

ssh does not hard-require keypairs. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/02/2019 20.01, Jim Henderson wrote:

On Mon, 11 Feb 2019 19:41:45 +0100, Liam Proven wrote:

...

The *only* way to win over such people is to ensure that there are no problems in their path. That everything works as they expect.

The question is understanding the expectations.

Most people want secure systems that are easy to use.

Making the system as secure as possible by default and presenting options to (for example) remove the blacklist entry when appropriate seems like the right path forward to me.

Leaving insecure/exploitable filesystems available by default, to me, seems like a really bad idea.

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. - -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas)) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXGHW2gAKCRC1MxgcbY1H 1TjoAJsGGbaTf59zjjCzv493SqIFe+GAIwCfeAS8GAjGQo7l1mAKiLnOVjnOrc0= =Ks6u -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

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)

On Tuesday, 12 February 2019 5:31:27 ACDT Jim Henderson wrote:

On Mon, 11 Feb 2019 19:41:45 +0100, Liam Proven wrote:

...

The *only* way to win over such people is to ensure that there are no problems in their path. That everything works as they expect.

The question is understanding the expectations.

Most people want secure systems that are easy to use.

In my experience, most people have no idea about security and want their computer to "just work". As long as their favourite games/word processor/ spreadsheet/<insert generic app class here> work without crashing, and their USB/portable hdd/<other removable storage devices> and other hardware simply "plug'n'play", and they can click on virus-and-malware-laden internet links to their hearts content (and they can ask their friendly neighbourhood "IT guy" to fix it when they inevitably break it), they're happy. Adding security features only gets in the way of most "users". That's why >90% of the worlds desktop/laptop computers are running Window$ (well, that and the fact that most of them come pre-installed and most people don't know any better). Your statement is likely correct of most Linux/MacOSX/<other Unix-based OS> users, and most corporate IT staff, but certainly not "most people" (IMHO). -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ==============================================================

On 2/11/19 9:08 PM, Carlos E. R. wrote:

I have been told the exact same thing - and I know it was not the same people, as these do not write English, and it was face to face.

I believe you. So this seems a goal to me. There is a *huge* problem with "Not Invented Here" attitude in the FOSS community. Vi users deride Emacs. Emacs users deride Vi. Atom ignores both and makes something much much easier. Then Microsoft comes along and outdoes Atom. Red Hat fans mock Ubuntu; Ubuntu fans mock Red Hat. But apart from some really quite small technical differences (APT versus RPM) for instance, they are very similar distros. Ubuntu pioneered an idea in Linux which others now copy: there's no accessible root account, and you use ``sudo'' to temporarily get permissions to do stuff. Where did that come from? Apple and Mac OS X. Maybe not the first, but it brought it to the masses, just like Apple popularized SCSI and Firewire and USB, too. The reaction of Linux people? Mockery and scorn. Just like with text editors. These days, Microsoft has realized that the Unix way of implementing a GUI OS, with a strict separation between graphical front-ends and rich powerful console-mode tools in the background, is a good thing. It helps scripting and automatic. It aids modularity. It means you can ship much smaller server OSes with a much smaller attack surface. So it's busily doing this to Windows Server. Apple takes whatever it feels like from FOSS and builds it into its products, replacing the contested or clunky parts with glossy closed-source replacements. Microsoft now is doing the same. What do Linux communities do? Fragment. Say "we don't do it that way and that is not important to us, so we will do a better way." Result... in the RPM world alone, there is YUM/DNF, and URPMI, and Zypper. Outside of that, there are multiple reinvented packaging systems -- Arch and Gentoo and Void and Alpine and so on, all with different ones. The real bitter unpleasant truth? Packaging is going away. Containers make it obsolete. All this reinventing wheels is a waste of time and effort, because really, Linux's niche is servers, and server workloads basically _all_ run in VMs, and containers are a lighter, more efficient kind of VM. In the desktop world, there are battles over whether panels go on the left or right or top or bottom, should there be one or two, should the user be able to customize them with lots of options dialog boxes, or config files, or by writing JavaScript add-ons. And which GUI toolkit should you use? And should coding be in C or C++ or Vala or JavaScript? Google comes along, offers to sell people cheap hardware with ChromeOS, a "distribution" with fewer options than anything else ever, and within a couple of years has more users than all the other desktop distros in the world put together. It offers no choices at all. You can't even install it on your own machine. But it's simple and it works. I do not have easy answers to any of these problems. I am merely pointing them out. In general, it is good policy to: * closely watch what your rivals are doing * copy what they do right and people like * add value where you can * add differentiation where you can And one thing is very clear from the success of Apple and Microsoft, ISTM. People like easy, simple, functional, get-the-job-done products. They don't want millions of options and choices to make. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday, 12 February 2019 12:12 Liam Proven wrote:

Ubuntu pioneered an idea in Linux which others now copy: there's no accessible root account, and you use ``sudo'' to temporarily get permissions to do stuff.

Not really. In Ubuntu, there is still an almighty root account with all consequences and hiding it does not change that. If you really want to move in the direction of solving the problem, you should rather learn SELinux, not praise Ubuntu for their pseudosecurity games. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday, 12 February 2019 15:04 Liam Proven wrote:

On 2/12/19 2:35 PM, Michal Kubecek wrote:

...

Not really. In Ubuntu, there is still an almighty root account with all consequences and hiding it does not change that. If you really want to move in the direction of solving the problem, you should rather learn SELinux, not praise Ubuntu for their pseudosecurity games.

That's what the word "accessible" was for. That was the reason I inserted it. You did notice it, right?

Yes there is a root account, but you can't log in, can't ``su'' to it or anything else.

...which is why people end up doing crazy things like "sudo su -". And, voilà, they have a root shell anyway, except all they needed was the regular user's password. That's supposed to be the security improvement, having to write "sudo su -" rather than just "su -"?

This is an example of a pragmatic improvement.

That's no improvement. That's an example of papering over problems which looks cool but does not in fact improve anything at all.

[1] It's a small change, it means only one password to remember (because 99% of modern end-user computers only have a single user for their entire life, so all the multiuser stuff is legacy cruft now for most users).

Use the same password for your regular user and root account then. You will also have "only one password to remember" and about the same level of "security" as in Ubuntu.

[2] It also removes the temptation to use the OS like Windows and always log in as the system administrator (as Puppy Linux does, for instance, which is just one of the reasons I don't recommend it. The creator came over from Windows 9x and doesn't understand the point behind user accounts.)

How exactly? By forcing you to type those 5 extra characters?

[3] It also means that there _is_ no hidden root password for anyone to find out, social engineer, whatever, and if they did find a way to get to the account, they couldn't log in anyway.

Except that there is regular user password which is sufficient to do anything so that the attacker does not need the root password and can "find out, social engineer, whatever" that one.

A small, simple, effective change, as opposed to a large, complex, system-wide change which broke lots of things. (And which, in the form of AppArmour, _additionally_ has an incompatible rival.)

Ever heard "For each complicated problem, there is an elegant, simple and easy to understand solution which has only one tiny weaknes: it does not actually solve the problem."? Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2/12/19 3:46 PM, Sid Boyce wrote:

This is an argument/flame war that surfaced here a long time back.

"sudo su" followed by "passwd root" and be done with the nonsense I argued but some saw it differently for reasons not understood, perhaps believing "sudo su" was a shield against having root access.

I am sure it is. However you're the second person to cite "sudo su" which is not the way that any experienced Ubuntu user does it. This makes me think that the people criticizing the behaviour, or the feature, are not experienced in actually using Ubuntu. It's a bad idea to criticize almost anything you haven't tried. "Try everything once except incest and folk dancing." -- Sir Thomas Beecham -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Feb 12, 2019 at 03:47:57PM +0100, Liam Proven wrote:

On 2/12/19 3:15 PM, Michal Kubecek wrote:

...

...which is why people end up doing crazy things like "sudo su -". And, voilà, they have a root shell anyway, except all they needed was the regular user's password. That's supposed to be the security improvement, having to write "sudo su -" rather than just "su -"?

``sudo -s'' is the easier way.

Which only supports my point.

...

...

This is an example of a pragmatic improvement.

That's no improvement.

I proceeded to list 3 ways it was an improvement. Rather than address them, you've made fun of them.

I did explain why all of them are wrong. If you call it "made fun", perhaps they are funny.

This means that you are actually _acting out_ the "not invented here" syndrome I was specifically addressing, you know that?

That's your perception and I have absolutely no idea how did you come to it.

Greater point missed: do you seriously think that the huge team of skilled engineers at the biggest computer company in history missed these points when they implemented this idea? Do you think you're smarter than everyone at Apple?

Honestly, this is a new low from you. Are you seriously trying the "proof by authority" trick? Well, I'm pretty sure many, perhaps even most developers at both Apple and Canonical realize how stupid the idea is but that doesn't stop their marketing from selling it as a great invention (compare with SLE 12->15 jump or even openSUSE 13->42->15 detour). What I find more disturbing is that you apparently buy it.

Or did you forget that this was not an Ubuntu innovation, it was an Apple one, which Ubuntu copied? Perhaps you were distracted by the chance to take some cheap shots at a rival distro. Suggestion: don't do that.

I don't care if it's Apple, Canonical or whoever. That idea being stupid has nothing to do with who came with it. If SUSE came with it, it would be just as stupid. You might have missed that I never held back from calling stupid ideas stupid when openSUSE came with them, both before I became an employee and after. In fact, I'm usually more likely to fight against stupid ideas in openSUSE as those do affect me directly.

...

How exactly? By forcing you to type those 5 extra characters?

If there's no root account available, you can't log in as it. This is not a hard point to understand.

One command is enough to give me a root login shell. What extra privileges would "logging in as it" give me? Absolutely none. What I need to get there? Knowledge of one password. What would I need in a normal distribution? Knowledge of one password. Actually, there is one difference: in normal model, it's a password which is only used when an administrative task is to be performed. In Ubuntu model, it's regular user's password, i.e. one which is used all the time, every time the user logs in, every time he unlocks the screen etc.

Up to Vista, in the Win NT family, on standalone machines, it was normal practice to log in as the administrator and use the machine that way.

(shrugs) People do a lot of stupid things. Not a reason to join them.

This was a terrible idea, but it was needed for a lot of software from the Win9x world to work, so that's what hundreds of millions of people were used to.

So, instead, you offer them working them under an account which, technically, is not a superuser but from practical point of view can do anything superuser can? Much better...

...

Except that there is regular user password which is sufficient to do anything so that the attacker does not need the root password and can "find out, social engineer, whatever" that one.

There is anyway. No real loss. But whereas a hacker knows the name of the root account because it's the same on almost all Unix machines, they don't know the username of the current owner/user.

Oh no, the "username as a second password" pseudoargument?

A more general lesson:

[1] "Those who cannot remember the past are condemned to repeat it." -- George Santayana [2] "Those who do not understand UNIX are condemned to reinvent it, poorly." -- Henry Spencer

I could also write a lot of completely irrelevant quotes but somehow I don't feel like it. To be honest, after you tried "proof by authority" and accused me of NIH which was based just on your imagination, I lost all interest in going on with this discussion. Enjoy your Ubuntu... Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2019-02-12 15:04, Liam Proven wrote:

Yes there is a root account, but you can't log in, can't ``su'' to it or anything else.

[2] It also removes the temptation to use the OS like Windows and always log in as the system administrator

You, sir, are full of nonsense. (1) Consumer Windows has moved away from the full-root design to a semi-root (role name in German: "Hauptbenutzer") IIRC that was between W98 and 2000 (the NT switch). That got tweaked over the last decade or so, culminating in the well-known UAC dialog boxes: https://docs.microsoft.com/en-us/windows/desktop/uxguide/images/winenv-uac-i... The right hand side is what's normally seen on desktop boxes. It's a one-click situation. (2) If anything, OSes like Ubuntu have converged to do it the Windows way: as every other command line in a HOWTO document has a "sudo" prefix these days, you are effectively root *all the time*, save for the bash instance you are typing at/in. (3) sudo's time-based credential cache which, where you enter the password once, and get free reign for a while is also pretty inviting to do root, similar to grudgingly dismissing the UAC box to get "work done".

[3] It also means that there _is_ no hidden root password for anyone to find out, social engineer,

Are you honestly so gullible to believe that? Now they will just social engineer the _regular_ password out of you. And if they are good, they will even sell it to you as a bonus that you did not need to give out the full access-bearing root password. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Liam Proven composed on 2019-02-12 15:04 (UTC+0100):

Michal Kubecek wrote:

...

Not really. In Ubuntu, there is still an almighty root account with all consequences and hiding it does not change that. If you really want to move in the direction of solving the problem, you should rather learn SELinux, not praise Ubuntu for their pseudosecurity games.

That's what the word "accessible" was for. That was the reason I inserted it. You did notice it, right?

Yes there is a root account, but you can't log in, can't ``su'' to it or anything else.

Sure you can. The only difference between Ubuntu and distros not based upon it is its installer does not demand root's password be set before proceeding with installation. Once installed, simply sudo passwd root and root's accessible just like any senior distro.

This is an example of a pragmatic improvement.

Not really. When there's a series of commands needed requiring root access, sudo space password must be prepended/appended for each command. It also makes search results confusing according to whether using a sudo installation or not, and whether the results assume it or not or make its need explicit, and which method a helper chooses or remembers whether needed in making a response to a help request. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Jim- I do have several horses in this race, and while it may be sensible in the near-term it does not address the underlying issue of insecure file systems regardless of their implementation. Per my previous reply, I strongly recommend the security risk be contained so that any file system regardless of its risks/vulnerabilities can be utilized. Pretty much all file systems have had or eventually will be a security risk regardless of implementation. Addressing this risk now should prevent future issues. Best, Jim On Thu, 2019-01-31 at 18:46 +0000, Jim Henderson wrote:

On Thu, 31 Jan 2019 13:42:14 -0500, Jim E Bonfiglio wrote:

...

Hi Jim- so far as I'm aware, thinking does not necessarily match reality. I couldn't tell you how many attend that conference, but I do wonder what a representative sample of (open)SUSE users would report as "necessary" file systems. Without such a sample this proposed change appears quite reckless.

Well, like I said, I don't have a horse in this race. It seems to me like a sensible move, with an easy solution for those who really need these filesystems.

-- Jim Henderson Please keep on-topic replies on the list so everyone benefits

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Simon- I would challenge you to examine the feasibility of such a containment across the entirety of the storage subsystem as this ought to be a significant value add to SLES customers, not to mention openSUSE users. As far as I'm aware it is not necessary to disable features of a subsystem to eliminate its attack surface. Per my previous reply to Martin Wilck, I would not complain should all file systems be "made secure" however I don't think that is necessary as all file systems have already had or willl very likely have in the future a security vulnerability discovered such that work becomes necessary to correct the vulnerability. In lieu of addressing each insecure file systems through correction or disablement, the attack surface could be eliminated instead vis-à-vis some sort of virtualized layer between the subsystem and its connecting components. In lieu of a virtualized layer between the subsystem and its connecting components, I suppose disabling the file systems would eliminate the current risk, but does not address future risk to any sort of CVE bulletin or other discovery regarding file system vulnerability. I strongly recommend addressing the root cause of this attack surface rather than reducing the size of the surface itself. Best, Jim On Fri, 2019-02-01 at 17:22 +1030, Simon Lees wrote:

On 01/02/2019 05:35, Jim E Bonfiglio wrote:

...

Hi Jim- I do have several horses in this race, and while it may be sensible in the near-term it does not address the underlying issue of insecure file systems regardless of their implementation.

Per my previous reply, I strongly recommend the security risk be contained so that any file system regardless of its risks/vulnerabilities can be utilized. Pretty much all file systems have had or eventually will be a security risk regardless of implementation. Addressing this risk now should prevent future issues.

Best, Jim

Such a containment across every filesystem is likely not possible otherwise we would already have it, the maintainers of the subsystem care about it enough to make it as secure as possible, likely to remove attack surfaces across the whole subsystem you'd have to start disabling features that people care about and use. The only software with no attack surfaces is a piece of software not capable of doing anything.

Fixing the issues in existing implementations takes time and effort clearly no one is stepping up to do this on older filesystems and seen as they don't have a business case for it SUSE is also not investing in such fixes and as such is disabling such filesystems. I think in this case openSUSE would be wise to adopt the same practices (unless someone misteriously shows up in the community willing to work on addressing the existing issues).

--

Simon Lees (Simotek) http://simotek.net

Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Stefan- per my previous mails implementing such a change/redesign of a storage subsystem is outside of my core competencies. Implementing such a change to the Linux kernel is also outside of my core competencies and also my capabilities. It's quite rude to tell me to do something beyond my capabilities when I have previously stated that I would be doing everyone a disservice by doing so. Further, I do not need to be told what to think by Martin Wilck. I couldn't tell you the reasons behind Linux kernel design decisions because I don't design and/or implement the Linux kernel. I have yet to see documentation of this offline meeting where a secret proposal is being worked on. I am extremely disappointed in the (open)SUSE community and still await the publication of the aforementioned secret proposal. Best, Jim On Sat, 2019-02-02 at 11:18 +0100, Stefan Seyfried wrote:

Hi Jim,

Am 01.02.19 um 18:42 schrieb Jim E Bonfiglio:

...

Per my previous reply to Martin Wilck, I would not complain should all file systems be "made secure" however I don't think that is necessary as all file systems have already had or willl very likely have in the future a security vulnerability discovered such that work becomes necessary to correct the vulnerability.

The file systems discussed here for blacklisting are rather obscure fringe use cases, and as such they have only relatively few users (*and developers*) who will be willing and able to fix such problems.

All the "big" file systems are actively maintained and get regular reviews, audits and fixes from upstream. That's the difference.

...

In lieu of addressing each insecure file systems through correction or disablement, the attack surface could be eliminated instead vis-à-vis some sort of virtualized layer between the subsystem and its connecting components.

Go ahead and do that. Do not talk about it. Do it. And make sure it performs well and gets accepted upstream.

This mailing list is not really the correct place to discuss redesigning the Linux Kernel VFS layer.

...

In lieu of a virtualized layer between the subsystem and its connecting components, I suppose disabling the file systems would eliminate the current risk, but does not address future risk to any sort of CVE bulletin or other discovery regarding file system vulnerability. I strongly recommend addressing the root cause of this attack surface rather than reducing the size of the surface itself.

Do it. And make sure it performs well and gets accepted upstream.

There is a reason the Linux Kernel is implemented as it is. Textbooks often say that it should be done different. But still the Linux Kernel is quite a success story.

(my signature quote fits surprisingly well today :) -- Stefan Seyfried

"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Andreas- should I take remarks from Stefan personally? I wasn't planning to, but I suppose I could now that you mention it. I'm not familiar with this Galaxy Hitchiking Guide you mention, but I am familiar with the Galaxy Express 999: Before humanity was born to this world, the stars shone in the heavens. Long after humanity is gone, the stars will continue to shine. While they live humanity looks up to the Sea of Stars and considers its own destiny. Everyone embarks on a journey dreaming of the Sea of Stars, chasing the pictures of one's dreams endlessly. While still on the road one eventually succumbs to an eternal sleep, though there may be many kilometers yet to go. Lives terminate, lives begin- the train runs through this endless flow. It carries on its infinite tracks the hopes, the ambition, and youth of all humanity. And for one youth the train runs again today. You are correct that I lack the expertise to implement my suggested implementation as I am generally business-facing. I proposed this implementation as a proof of concept; as such, this proof of concept does not necessitate credibility as an actual production implementation. If you would like to chastise my personal credibility, I don't care. As far as I'm aware I am a customer of the (open)SUSE distribution and have raised this concern so that this concern can be attended to. How you choose to proceed with this concern is your decision. How you choose to react or respond to this concern is also your decision. If you don't want to implement this or see to it such that this is implemented, why not just say so? I have yet to see a posting of the secret proposal previously mentioned in this thread. I am disappointed in the lack of transparency offered by the openSUSE and SUSE communities at large. Best, Jim On Sat, 2019-02-02 at 22:02 +0100, Andreas Mahel wrote:

Hi Jim,

Am Samstag, 2. Februar 2019, 18:31:01 CET schrieb Jim E Bonfiglio:

...

Hi Stefan- per my previous mails implementing such a change/redesign of a storage subsystem is outside of my core competencies. Implementing such a change to the Linux kernel is also outside of my core competencies and also my capabilities. It's quite rude to tell me to do something beyond my capabilities when I have previously stated that I would be doing everyone a disservice by doing so. Further, I do not need to be told what to think by Martin Wilck.

I couldn't tell you the reasons behind Linux kernel design decisions because I don't design and/or implement the Linux kernel. I have yet to see documentation of this offline meeting where a secret proposal is being worked on. I am extremely disappointed in the (open)SUSE community and still await the publication of the aforementioned secret proposal.

Don't take remarks like the one from Stefan too personal. As I see it, they are an expression of frustration about too many people offering advice which actually is none (or at least not a good one).

Looking at what you proposed, which was something along the lines of introducing "some sort of virtualized layer between the subsystem and its connecting components".

This may or may not be a good idea, however, as long as it is not backed by sufficient manpower to actually implement it, it's just that - an idea. In addition, you are stating yourself that you don't have expertise in the relevant areas of storage subsystems and kernel design. This puts the credibility of your proposal strongly in the direction of what the hitchhiker's guide to the galaxy denotes as "seemed to be a good idea at the time".

Let's assume now that we actually got some developers eager to work on what you proposed, and that your proposal actually is a way to eliminate the security risks. What timeline would you expect for this to be implemented and integrated into the kernel? I'd bet it would take quite some time - after all it fiddles with some of the core components of the system, and messing this up is just not an option. Until then, the attack surface would remain unchanged.

So even in the most optimistic case that your proposal could serve as a solution and would be implemented, it still does not solve the problem at hand. And as such, the proposal is not really too valuable in the context of this thread. Which makes it understandable when people get a bit harsh.

Ah, and one last thing: it would be nice if you could refrain from top posting, and place your replies inline instead. That's how it's done around here, and following a thread is much easier when everyone is quoting / posting by the same conventions.

/Andreas

...

On Sat, 2019-02-02 at 11:18 +0100, Stefan Seyfried wrote:

...

Hi Jim,

Am 01.02.19 um 18:42 schrieb Jim E Bonfiglio:

...

Per my previous reply to Martin Wilck, I would not complain should all file systems be "made secure" however I don't think that is necessary as all file systems have already had or willl very likely have in the future a security vulnerability discovered such that work becomes necessary to correct the vulnerability.

The file systems discussed here for blacklisting are rather obscure fringe use cases, and as such they have only relatively few users (*and developers*) who will be willing and able to fix such problems.

All the "big" file systems are actively maintained and get regular reviews, audits and fixes from upstream. That's the difference.

...

In lieu of addressing each insecure file systems through correction or disablement, the attack surface could be eliminated instead vis-à-vis some sort of virtualized layer between the subsystem and its connecting components.

Go ahead and do that. Do not talk about it. Do it. And make sure it performs well and gets accepted upstream.

This mailing list is not really the correct place to discuss redesigning the Linux Kernel VFS layer.

...

In lieu of a virtualized layer between the subsystem and its connecting components, I suppose disabling the file systems would eliminate the current risk, but does not address future risk to any sort of CVE bulletin or other discovery regarding file system vulnerability. I strongly recommend addressing the root cause of this attack surface rather than reducing the size of the surface itself.

Do it. And make sure it performs well and gets accepted upstream.

There is a reason the Linux Kernel is implemented as it is. Textbooks often say that it should be done different. But still the Linux Kernel is quite a success story.

(my signature quote fits surprisingly well today :)

-- Time flies like an arrow. Fruit flies like a banana.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Simon- I don't care to dig through my emails again to justify my observations. Have fun with your distribution. Best, Jim On Tue, 2019-02-05 at 19:34 +1030, Simon Lees wrote:

On 05/02/2019 08:33, Jim E Bonfiglio wrote:

...

As far as I'm aware I am a customer of the (open)SUSE distribution and have raised this concern so that this concern can be attended to. How you choose to proceed with this concern is your decision. How you choose to react or respond to this concern is also your decision. If you don't want to implement this or see to it such that this is implemented, why not just say so? I have yet to see a posting of the secret proposal previously mentioned in this thread.

I am disappointed in the lack of transparency offered by the openSUSE and SUSE communities at large.

I have no idea what secret proposal you are talking about the original email started with a clear proposal with clear reasoning and was asking for any objections to implementing the proposal. I'm not quite sure how much more transparent the people wanting to make this change could be. All of openSUSE's code is publicly available and all changes to openSUSE are peer reviewed so its very hard to sneak any change in.

In openSUSE the people willing to do the work are generally the ones who get to make the decisions although they are encoraged to get feedback / discussion on potentially controversial issues or other major changes on this list. SUSE on the other hand has product managers who act in what they believe will be the best interest of its customers based off the feedback they receive.

Either way can you suggest some ways the openSUSE community could be more transparent, I as a member of the openSUSE board am welcome to hearing ideas on this.

Cheers

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Liam Proven <lproven@suse.cz> [02-05-19 12:44]:

On 2/4/19 11:03 PM, Jim E Bonfiglio wrote:

...

I'm not familiar with this Galaxy Hitchiking Guide you mention, but I am familiar with the Galaxy Express 999:

Offtopic. I am astonished.

I admit to bias: I am a former president of the Douglas Adams fanclub.

But it's a vastly successful radio series, book series, computer game, album, graphic novel, movie, and towel. It's a lot better known than the manga you cite, which I had to Google.

It's also older.

You should read it.

and it might even be OFF TOPIC -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 02/02/2019 04:12, Jim E Bonfiglio wrote:

Hi Simon- I would challenge you to examine the feasibility of such a containment across the entirety of the storage subsystem as this ought to be a significant value add to SLES customers, not to mention openSUSE users. As far as I'm aware it is not necessary to disable features of a subsystem to eliminate its attack surface.

Per my previous reply to Martin Wilck, I would not complain should all file systems be "made secure" however I don't think that is necessary as all file systems have already had or willl very likely have in the future a security vulnerability discovered such that work becomes necessary to correct the vulnerability. In lieu of addressing each insecure file systems through correction or disablement, the attack surface could be eliminated instead vis-à-vis some sort of virtualized layer between the subsystem and its connecting components.

In lieu of a virtualized layer between the subsystem and its connecting components, I suppose disabling the file systems would eliminate the current risk, but does not address future risk to any sort of CVE bulletin or other discovery regarding file system vulnerability. I strongly recommend addressing the root cause of this attack surface rather than reducing the size of the surface itself.

Best, Jim

Well that is also well outside my scope, Given SUSE's upstream first policy such a set of changes would have to be developed in the upstream kernel before we adopted them. In SUSE / openSUSE, even if someone is willing to completely revamp the storage subsystem and do it in such a way that doesn't cause a significant performance hit the process will still take at least a year likely more before it reaches our kernels which means we need to do something in the mean time of which disabling uncommonly used and not well maintained filesystems makes sense. Even if it was re written it would still have bugs as any sufficiently complex software does and eventually someone would find a way to exploit such. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On 05/02/2019 08:33, Jim E Bonfiglio wrote:

Hi Simon- as far as I'm aware the currently insecure file system implementations you are seeking to disable also possess bugs and known exploits. While my proposal would not necessarily reduce bugs in sum total, it ought to eliminate the necessity to concern oneself with insecure file systems which possess bugs and known exploits.

By "virtualizing" or "extrapolating" the file system subsystem, these buggy and known exploitable file systems (pretty much all of them) could be contained rather than be removed and/or patched. This may provide more flexibility to users of (open)SUSE, or, the general Linux community at large should this be implemented upstream as previously mentioned.

I hope this email provides clarity.

I understand what your saying, I'm just trying to point out that what you suggest is likely not feesable for the openSUSE project to implement on its own. openSUSE is a volunteer organisation unless someone volunteers to change / implement / fix something it doesn't happen. Currently no one is volunteering to do the complex work that you suggest, however someone has volunteered to fix the issues related to these insecure filesystems in a simpler way and a way in which they have time to contribute. So unless someone steps up and volunteers to do it in another way I don't see why we shouldn't it doesn't seem to be an unreasonable way forward. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On 06/02/2019 04.36, Jim E Bonfiglio wrote:

Hi Simon- if the (open)SUSE community is just that impotent I'll take my leave.

I'm sorry to say that what you ask is simply impossible to do. Your assumptions about openSUSE are plain wrong. If you want such a change to how filesystems are handled, you should convince Linus Torvalds and sufficient people of the kernel developers, not openSUSE. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 06/02/2019 19.34, Jim E Bonfiglio wrote:

Hi Simon- as far as I'm aware I am not making assumptions, merely communicating my observations. It appears that the (open)SUSE community/corporation lacks any process to escalate such risks, suggestions, and/or recommendations upstream. As such, this simply is not the distribution for me to use for any use case in any domain.

Any distribution will tell you the same thing. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On Thu, 2019-02-07 at 09:16 +1030, Simon Lees wrote:

We actually have quite a simple policy:   1. File a bug report 2. The maintainer will then decide on the following.    a. Its an openSUSE issue.       i. Then they can decide to add it to there todo list       ii. or mark it as wont fix because they don't have time to do it    b. Its an upstream issue       i. They can point you to the upstream location for suggesting features / enhancements (preferable)       ii. Suggest the feature on your behalf (generally if they also agree its something they want to see).       iii. If your extra lucky they might just implement it upstream.       iv. They may say the idea is likely unfeasible or wont be accepted upstream because similar ideas in the past have been rejected.     Bug reports are handled differently of course. Especially those related to security issues.

Hi Simon- per your request I have two questions for you: 1. Is this to-be-implemented blacklist a feature or a bug? 2. What is the purpose of this mailing list? I have observed discussions related to the determination of bugs in this list. Should this list be utilized for this purpose or for a different purpose? As far as I'm aware bugs are fair game for discussion here, though perhaps the openSUSE forum may be more appropriate? Best, Jim On Thu, 2019-02-07 at 09:16 +1030, Simon Lees wrote:

Please stop top posting.

On 07/02/2019 05:04, Jim E Bonfiglio wrote:

...

Hi Simon- as far as I'm aware I am not making assumptions, merely communicating my observations. It appears that the (open)SUSE community/corporation lacks any process to escalate such risks, suggestions, and/or recommendations upstream. As such, this simply is not the distribution for me to use for any use case in any domain.

Best, Jim

We actually have quite a simple policy:

1. File a bug report 2. The maintainer will then decide on the following.    a. Its an openSUSE issue.       i. Then they can decide to add it to there todo list       ii. or mark it as wont fix because they don't have time to do it    b. Its an upstream issue       i. They can point you to the upstream location for suggesting features / enhancements (preferable)       ii. Suggest the feature on your behalf (generally if they also agree its something they want to see).       iii. If your extra lucky they might just implement it upstream.       iv. They may say the idea is likely unfeasible or wont be accepted upstream because similar ideas in the past have been rejected.

Bug reports are handled differently of course. Especially those related to security issues.

...

On Wed, 2019-02-06 at 11:57 +0100, Carlos E. R. wrote:

...

On 06/02/2019 04.36, Jim E Bonfiglio wrote:

...

Hi Simon- if the (open)SUSE community is just that impotent I'll take my leave.

I'm sorry to say that what you ask is simply impossible to do. Your assumptions about openSUSE are plain wrong.

If you want such a change to how filesystems are handled, you should convince Linus Torvalds and sufficient people of the kernel developers, not openSUSE.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Jeff- thank you for providing me that information, however as far as I'm aware this is the first time that this list has been suggested to me. Not once have I used the "microkernel" word, though I don't disagree that a microkernel architecture could address this concern I have raised. I don't disagree with you that the blacklist is a low effort method of addressing specific insecure file systems, however per previous emails it still does not contain the risk itself. It appears that this unmitigated risk will not be pursued by the (open)SUSE community and/or corporation; as such, I will take my leave. Best, Jim On Wed, 2019-02-06 at 08:56 -0700, Jeff Mahoney wrote:

On 2/4/19 3:03 PM, Jim E Bonfiglio wrote:

...

Hi Simon- as far as I'm aware the currently insecure file system implementations you are seeking to disable also possess bugs and known exploits. While my proposal would not necessarily reduce bugs in sum total, it ought to eliminate the necessity to concern oneself with insecure file systems which possess bugs and known exploits.

By "virtualizing" or "extrapolating" the file system subsystem, these buggy and known exploitable file systems (pretty much all of them) could be contained rather than be removed and/or patched. This may provide more flexibility to users of (open)SUSE, or, the general Linux community at large should this be implemented upstream as previously mentioned. 

I hope this email provides clarity.

As stated previously, this is the wrong list for such discussion. linux-fsdevel is the place for linux-wide file system developement, not a single distro's rolling release topic list.

What you suggest is to turn Linux into a microkernel architecture.  It's been tried, specifically in the storage domain.  Here's one recent attempt: https://www.flux.utah.edu/paper/235

From the paper: """ We concluded that, while it is theoretically possible to isolate unmodified code, doing so in a way that preserves strong, byte level coherence leads to too much performance overhead and engineering complexity. Components in a shared memory program are interwoven with call patterns and data flows that are too complex to break apart without modification. We also concluded that it is difficult for domains to be lightweight. """

IOW, "a cool project but the performance sucks."

That reads pretty much like every analysis of every attempt to convert a monokernel to a microkernel architecture.

The other "big" alternative is to create a library that allows any file system to be compiled as a fuse module.

In either case, if it's a solution you want, you will either need to write it yourself or find someone willing to accept payment from you to do it.  To suggest that others perform the work to implement your ideas is considered especially rude in a community setting.

The approach taken by the blacklist is a low-cost, low-effort way to reduce the attack surface for the vast majority of users.  As has been stated elsewhere, the high-use file systems are well maintained and security vulnerabilities are fixed as quickly as possible.

-Jeff

...

On Mon, 2019-02-04 at 14:55 +1030, Simon Lees wrote:

...

On 02/02/2019 04:12, Jim E Bonfiglio wrote:

...

Hi Simon- I would challenge you to examine the feasibility of such a containment across the entirety of the storage subsystem as this ought to be a significant value add to SLES customers, not to mention openSUSE users. As far as I'm aware it is not necessary to disable features of a subsystem to eliminate its attack surface.

Per my previous reply to Martin Wilck, I would not complain should all file systems be "made secure" however I don't think that is necessary as all file systems have already had or willl very likely have in the future a security vulnerability discovered such that work becomes necessary to correct the vulnerability. In lieu of addressing each insecure file systems through correction or disablement, the attack surface could be eliminated instead vis-à-vis some sort of virtualized layer between the subsystem and its connecting components.

In lieu of a virtualized layer between the subsystem and its connecting components, I suppose disabling the file systems would eliminate the current risk, but does not address future risk to any sort of CVE bulletin or other discovery regarding file system vulnerability. I strongly recommend addressing the root cause of this attack surface rather than reducing the size of the surface itself.

Best, Jim

Well that is also well outside my scope, Given SUSE's upstream first policy such a set of changes would have to be developed in the upstream kernel before we adopted them. In SUSE / openSUSE, even if someone is willing to completely revamp the storage subsystem and do it in such a way that doesn't cause a significant performance hit the process will still take at least a year likely more before it reaches our kernels which means we need to do something in the mean time of which disabling uncommonly used and not well maintained filesystems makes sense.

Even if it was re written it would still have bugs as any sufficiently complex software does and eventually someone would find a way to exploit such.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Jeff- who should this be easy for? Automatic culling of the blacklist may result in unexpected behavior for those not initiated. Best, Jim On Thu, 2019-01-31 at 14:06 -0500, Jeff Mahoney wrote:

On 1/31/19 1:46 PM, Jim Henderson wrote:

...

On Thu, 31 Jan 2019 13:42:14 -0500, Jim E Bonfiglio wrote:

...

Hi Jim- so far as I'm aware, thinking does not necessarily match reality. I couldn't tell you how many attend that conference, but I do wonder what a representative sample of (open)SUSE users would report as "necessary" file systems. Without such a sample this proposed change appears quite reckless.

Well, like I said, I don't have a horse in this race. It seems to me like a sensible move, with an easy solution for those who really need these filesystems.

Our goal is to make it as easy as possible. I believe the combination of one-blacklist-per-file and automatic culling of the blacklist at package install/update time based on the content of /proc/filesystems (or fstab) will be a good way to do that.

-Jeff

-- Jeff Mahoney SUSE Labs

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 31/01/2019 20.43, Jeff Mahoney wrote:

Now that I look at it again, the list was composed using the file systems we build on SLE15. There are two others that should be added: omfs ntfs[3]

-Jeff [3] Not that NTFS isn't widely used; Just that the only attention that the ntfs kernel module has has seen since 2007 has been for tree-wide cleanups and API changes. Use ntfs-3g instead.

The default is using ntfs-3g, even writing "ntfs" on fstab. I doubt anybody now uses the kernel one, as it doesn't support enough features. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

On 1/31/19 2:52 PM, Jim E Bonfiglio wrote:

Hi Jeff- have data been gathered regarding these file systems which the "vast majority of users" use? If so, where might I find these data? Does SUSE or anyone else gather these data regarding users of (open)SUSE? If so, how are these data gathered?

Best, Jim

On Thu, 2019-01-31 at 14:43 -0500, Jeff Mahoney wrote:

...

On 1/31/19 1:42 PM, Jim E Bonfiglio wrote:

...

Hi Jim- so far as I'm aware, thinking does not necessarily match reality. I couldn't tell you how many attend that conference, but I do wonder what a representative sample of (open)SUSE users would report as "necessary" file systems. Without such a sample this proposed change appears quite reckless.

Best, Jim

On Thu, 2019-01-31 at 16:45 +0000, Jim Henderson wrote:

...

On Thu, 31 Jan 2019 04:37:08 -0500, Felix Miata wrote:

...

And yet there are enough to manage to have an annual convention: http://www.warpstock.org/

I don't have a horse in this race, but going to the site for the Berlin 2018 conference doesn't make me think that this affects thousands of users. It makes me think it affects about 20. Small conference rooms, a relatively small lunch gathering. Makes me wonder what the actual attendance is.

The solution is simple - remove the filesystem from the blacklist. Seems like a really easy thing to do for something that's used by 20 people.

It's not like the filesystem module is not being built or included.

In terms of local file systems, the vast majority of users use: ext2/3/4, xfs, btrfs, and reiserfs[1]. OCFS2 and GFS2 are common enough that I wouldn't want to blacklist them. JFS saw some use in the past but it was never particularly popular since it was the disk format used by OS/2 and not the AIX version. My opinions on it aren't new[2]. The rest are for compatibility with now-ancient or otherwise uncommon OSes, for pure flash (ie: without an FTL) media, or have other maintenance issues (f2fs). Are there users out there for any of these? I'm sure there are a handful. I just don't think it's worth leaving the attack surface open for the vast majority of users to accommodate a few -- especially if we can minimize the impact on the few.

Now that I look at it again, the list was composed using the file systems we build on SLE15. There are two others that should be added: omfs ntfs[3]

-Jeff

[1] I expect this will go on the blacklist at some point in the future as I'm the last person to do any real work on it and I have other priorities that take precedence. [2] https://sourceforge.net/p/jfs/mailman/jfs-discussion/thread/fpps5p$g2t$2@sat... -- I'm assuming the staff member was me in this case. Dave also says that he tries to fix bugs but the hard ones go unfixed. This was 11 years ago. [3] Not that NTFS isn't widely used; Just that the only attention that the ntfs kernel module has has seen since 2007 has been for tree-wide cleanups and API changes. Use ntfs-3g instead.

Please observe the list convention and refrain from top-posting. We don't have specific data because we don't do install tracking beyond the standard http logs which don't yield anything more concrete than the number of unique users who downloaded a package. If you'd like to propose deeper, more fine-grained statistics, you're welcome to lead that discussion. This is anecdata based on experience. I've been a contributing member of the Linux file system community for 19 years and have led the SUSE kernel file system team for the last 12. All software has bugs and the lack of bug reports for e.g. befs doesn't mean that it's perfect. It means so few people use it that they're not hitting any. Mailing list activity may also be decent metric of activity and popularity. The btrfs list had 12600 message last year and 897 messages since 1 January 2019. The XFS last had 10200 message last year and 571 since the start of 2019. I don't keep an archive of the ext4 list, but some screen scraping says about 4700 messages last year and 330 message this year so far. I wouldn't use these numbers to /rank/ popularity, but they're sufficient to show that the communities are still active. In contrast, the JFS list had 229 messages last year, most of which were courtesy CC's for tree-wide API changes. ReiserFS had even fewer, but it was our default file system for several years (and, as I said, it'll be added eventually). In terms of commit activity, qnx6 has been largely untouched since it's initial commit in 2012. The last time the qnx4 maintainer committed code he wrote was in 2009 and that was to remove write support entirely. All changes since then have been janitor-style changes. The last substantial changes to adfs were in 2011. I know HFS is unmaintained because I saw a CVE relating to it show up this year and everyone shrugged. The list reflects reality and the blacklist is the most user-friendly solution to shrink the attack surface while allowing flexibility of deployment. -Jeff -- Jeff Mahoney SUSE Labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org