linux-kernel - Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190831064616.GA13286@infradead.org>
Date:   Fri, 30 Aug 2019 23:46:16 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Valdis Klētnieks <valdis.kletnieks@...edu>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sasha Levin <alexander.levin@...rosoft.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of
 fat/vfat

On Fri, Aug 30, 2019 at 08:48:36PM -0400, Valdis Klētnieks wrote:
> Explain how it's half-a**ed.  You worry about accidental mounting, meanwhile
> down in the embedded space there are memory-constrained machines that
> don't want separate vfat and exfat drivers sitting around in memory. If you
> have a better patch that addresses both concerns, feel free to submit it.

Since when did Linux kernel submissions become "show me a better patch"
to reject something obviously bad?

As I said the right approach is to probably (pending comments from the
actual fat maintainer) to merge exfat support into the existing fs/fat/
codebase.  You obviously seem to disagree (and at the same time not).

But using this as a pre-text of adding a non-disabled second fat16/32
implementation and actually allowing that to build with no reason is
just not how it works.

> > done.  Given that you signed up as the maintainer for this what is your
> > plan forward on it?  What development did you on the code and what are
> > your next steps?
> 
> Well, the *original* plan was to get it into the tree someplace so it can get
> review and updates from others.

In other words you have no actual plan and no idea what to do and want to
rely on "others" to do anything, but at the same time reject the
comments from others how to do things right?

> Given the amount of press the Microsoft
> announcement had, we were *hoping* there would be some momentum and
> people actually looking at the code and feeding me patches. I've gotten a
> half dozen already today....

And all of that you can easily do by just sending out a patch series.
And maybe actually listening to comments.

> Although if you prefer, it can just sit out-of-tree until I've got a perfect driver
> without input or review from anybody.  But I can't think of *any* instance where
> that model has actually worked.

You generally get a lot of review and comments by posting to the mailing
list.  But what really helps is to just do the very basic homework
beforehand.  And it also really helps to have a plan what you want to
do with a codebase you just copy and pasted from somewhere.