On Jan 31, 2026, at 12:54 PM, David A. Wheeler via austin-group-l at The Open Group <[email protected]> wrote:
> I previously proposed that at least \n, and preferably all control characters > (bytes 1-31 in ASCII & UTF-8), > be expressly *forbidden* in filenames: > https://austingroupbugs.net/view.php?id=251 > There is no user-level functionality *requiring* this capability, several > systems > (like MacOS) already forbid them, That may have been the case on HFS+, but it's not the case on APFS - I tested it. (I think allowing that may have been an explicit design choice in APFS.) > Arbitrary values like an unconfigurable "X% of RAM" limit don't > help security. They would make systems LESS secure, because they'd > sometimes give attackers an easy way to remotely disable systems. > That would also increase the burden on developers, who would suddenly > have to code around weird arbitrary limits of their underlying system. > Even adding special configuration capabilities has problems, because now > users have to figure out a new special configuration. Yes, and... > If you can show a *specific* kind of vulnerability due to a lack of > input validation, and an input validation for that specific API that would > apply in all cases and counter it, then that might be worth proposing. ...yes.
