News for hackers. Stuff that matters.
Re:Glibc Buffer Overflow in Iconv by jcranmer on Sunday April 21, 2024 @02:49PM (#40108162)
To be honest, I disagree. Unix filenames are printable text, they're just text that the OS chooses not to enforce any validation on. Especially since the charset is implied by your choice of locale, which is a user decision, not a kernel decision. But we've transitioned into a world where pretty much all systems have settled on UTF-8 as the charset of choice, and the OS's refusal to even permit kernel options to forcibly validate filenames as UTF-8 is starting to look like a poor decision.

(IIRC, at least one of the BSDs has actually moved to forcing filenames to be UTF-8 and refusing path names that aren't UTF-8. Would only that Linux moved down that path as well so that we could be done with this farce.)

Re:Glibc Buffer Overflow in Iconv by SAI_Peregrinus on Sunday April 21, 2024 @05:07PM (#40109264)
A filename consisting of nothing but ASCII Bell characters (0x07) is valid. Those are non-printable characters that (used to) make a sound from the PC's speaker. POSIX filenames can be sound, not text.

I'd agree it'd be nice if we could restrict filenames to valid UTF-8. But that's not the API that existing filesystems provide, nor what (most of) the existing OSes enforce.

Re:Glibc Buffer Overflow in Iconv by glandium on Sunday April 21, 2024 @09:54PM (#40110847)
Note that BEL(0x07) is valid UTF-8.
Re:Glibc Buffer Overflow in Iconv by snnn on Sunday April 21, 2024 @07:59PM (#40110289)
Kernel developers need to consider backwards compatibility. You won't want to see some users lose their data because they upgraded the kernel. Therefore it is very hard to "force" something.
Re:Glibc Buffer Overflow in Iconv by jcranmer on Sunday April 21, 2024 @11:38PM (#40111230)
Filesystem mount option, have utilities default it to on when creating new partitions.