linux-kernel - Re: [GIT PULL] bcachefs fixes for 6.15-rc4

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: <114E260B-7AC4-4F5D-BBC4-60036CC7188F@zytor.com>
Date: Wed, 30 Apr 2025 20:32:03 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: "Theodore Ts'o" <tytso@....edu>,
        Kent Overstreet <kent.overstreet@...ux.dev>,
        linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs fixes for 6.15-rc4

On April 30, 2025 8:12:20 PM PDT, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>On Wed, 30 Apr 2025 at 19:48, H. Peter Anvin <hpa@...or.com> wrote:
>>
>> It is worth noting that Microsoft has basically declared their
>> "recommended" case folding (upcase) table to be permanently frozen (for
>> new filesystem instances in the case where they use an on-disk
>> translation table created at format time.)  As far as I know they have
>> never supported anything other than 1:1 conversion of BMP code points,
>> nor normalization.
>
>So no crazy 'ß' matches 'ss' kind of thing? (And yes, afaik that's
>technically wrong even in German, but afaik at least sorts the same in
>some locales).
>
>Because yes, if MS basically does a 1:1 unicode translation with a
>fixed table, that is not only "simpler", I think it's what we should
>strive for.
>
>Because I think the *only* valid reason for case insensitive
>filesystems is "backwards compatibility", and given that, it's
>_particularly_ stupid to then do anything more complicated and broken
>than the thing you're trying to be compatible with.
>
>I hope to everything holy that nobody ever wants to be compatible with
>the absolute garbage that is the OSX HFS model.
>
>Because the whole "let's actively corrupt names into something that is
>almost, but not exactly, NFD" stuff is just some next-level evil
>stuff.
>
>            Linus
>

I suspect the NFD bit in HFS comes from the use of decomposed characters in the 8-bit character systems of MacOS Classic.