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: <339527.1567309047@turing-police>
Date:   Sat, 31 Aug 2019 23:37:27 -0400
From:   "Valdis Klētnieks" <valdis.kletnieks@...edu>
To:     Dave Chinner <david@...morbit.com>
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 Sun, 01 Sep 2019 11:07:21 +1000, Dave Chinner said:
> Totally irrelevant to the issue at hand. You can easily co-ordinate
> out of tree contributions through a github tree, or a tree on
> kernel.org, etc.

Well.. I'm not personally wedded to the staging tree.  I'm just interested in
getting a driver done and upstreamed with as little pain as possible. :)

Is there any preference for github versus kernel.org?  I can set up a github
tree on my own, no idea who needs to do what for a kernel.org tree.

Also, this (from another email of yours) was (at least to me) the most useful
thing said so far:

> look at what other people have raised w.r.t. to that filesystem -
> on-disk format validation, re-implementation of largely generic
> code, lack of namespacing of functions leading to conflicts with
> generic/VFS functionality, etc.

All of which are now on the to-do list, thanks.

Now one big question:

Should I heave all the vfat stuff overboard and make a module that
*only* does exfat, or is there enough interest in an extended FAT module
that does vfat and extfat, in which case the direction should be to re-align
this module's code with vfat?

> That's the choice you have to make now: listen to the reviewers
> saying "resolve the fundamental issues before goign any further",

Well... *getting* a laundry list of what the reviewers see as the fundamental
issues is the first step in resolving them ;)

Content of type "application/pgp-signature" skipped