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: <20181208183637.GD20708@thunk.org>
Date:   Sat, 8 Dec 2018 13:36:37 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Gabriel Krisman Bertazi <krisman@...labora.com>
Cc:     linux-ext4@...r.kernel.org, kernel@...labora.com
Subject: Re: [PATCH] e2p: Print encoding information in superblock dump

On Tue, Dec 04, 2018 at 04:16:09PM -0500, Gabriel Krisman Bertazi wrote:
> diff --git a/lib/e2p/ls.c b/lib/e2p/ls.c
> index a7586e094da1..bb1fc8aa94da 100644
> --- a/lib/e2p/ls.c
> +++ b/lib/e2p/ls.c
    ....
> +	if (encoding == EXT4_ENC_UTF8_11_0) {
> +		if (flags & EXT4_UTF8_NORMALIZATION_TYPE_NFKD)
> +			fputs(" NFKD", f);
> +		else
> +			fputs(" Unnormalized", f);
> +		flags_found++;
> +
> +		if (flags & EXT4_UTF8_CASEFOLD_TYPE_NFKDCF)
> +			fputs(" NFKDCF", f);
> +		else
> +			fputs(" toUpper", f);
> +		flags_found++;
> +	}

I don't understand this.  Why is "toUpper" the opposite of
"CASEFOLD_TYPE_NFKDCF"?  From what I can tell looking at the kernel
patches, it appears that if CASEFOLD_TYPE_NFKDCF is not specified, no
case folding is done at all.  And it appears the opposite of "toupper"
is "tolower" --- for ASCII case folding.

More generally, we don't have a way of setting these flags, and I'm
wondering if we should just make a decision and be done with it.
After all, without any way of changing the flags, there's only one
code path that is going to be well tested, and realistically user
programs will come to *expect* only one way file systems will do
things.  The MacOS world has discovered the hard way what happens if
they try to change normalization conventions from one to another,
leading to all sorts of confusion for application programmers.

So perhaps we should just remove these flags from the superblock, and
only support one way of doing things.  We ask the opinion of various
stake-holders --- the Samba folks, fsdevel, Steam, etc.  But whether
we decide NFC, NFD, NFKC or NFKD, I suspect we'll be better off just
picking one and only one way of doing things.   WDYT?

	    	     	     	      		- Ted

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ