Re: [PATCH 4/6] xfs_db: fix metadump name obfuscation for ascii-ci filesystems

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Apr 12, 2023 at 05:09:56AM -0700, Christoph Hellwig wrote:
> On Tue, Apr 11, 2023 at 08:35:46AM -0700, Darrick J. Wong wrote:
> > > obsfucate some names this really seems horribly ugly.  I could
> > > come up with ideas to fix some of that, but they'd be fairly invasive.
> > 
> > Given that it's rol7 and xoring, I'd love it if someone came up with a
> > gentler obfuscate_name() that at least tried to generate obfuscated
> > names that weren't full of control characters and other junk that make
> > ls output horrible.
> > 
> > Buuuut doing that requires a deep understanding of how the math works.
> > I think I've almost grokked it, but applied math has never been my
> > specialty.  Mark Adler's crc spoof looked promising if we ever follow
> > through on Dave's suggestion to change the dahash to crc32c, but that's
> > a whole different discussion.
> 
> Agreed on all counts.
> 
> > > Is there any reason we need to support obsfucatation for ascii-ci,
> > > or could we just say we require "-o" to metadump ascii-ci file systems
> > > and not deal with this at all given that it never actually worked?
> > 
> > That would be simpler for metadump, yes.
> > 
> > I'm going to introduce a followup series that adds a new xfs_db command
> > to generate obfuscated filenames/attrs to exercise the dabtree hash
> > collision resolution code.  I should probably do that now, since I
> > already sent xfs/861 that uses it.
> > 
> > It wouldn't be the end of the world if hashcoll didn't work on asciici
> > filesystems, but that /would/ be a testing gap.
> 
> Do we really care about that testing gap for a feature you just
> deprecated and which has been pretty broken all this time?

I don't, and am perfectly happy to send an alternate patch that errors
out if you try to obfuscate an asciici filesystem.  Or maybe doesn't
even error out, since names less than 5 letters aren't obfuscated, so
it's not like we're hiding things effectively anyway.

That said, Carlos is the maintainer, so let's let him decide. :D

1) Gross loopy code; or
2) Less test coverage of broken code; or
3) Control gross loopy code with a flag so that debugger commands can
   still do gross things, but metadump won't.

--D