On Feb 1, 2026, at 12:38 AM, Amit via austin-group-l at The Open Group <[email protected]> wrote:
> Minorities can get around my limitation of limiting all inputs to a maximum > of 75% of the RAM size in 2 ways: > > 1. Increase the RAM size. > 2. Modify the source code and remove the checks. 3) demonstrate that imposing the limits does not actually do anything for the benefit of the majority, as the lack of limits on the size of inputs to functions are not the cause of all buffer overflows, and get the limitations removed, so that neither the majority nor the minority suffers. > > If we satisfy the minority, then this will mean that we are putting the > majority > of the users at the risk of getting hacked and active hacking is happening > even today. > > I started following the hacking news from August 2024 and even till > now hacking is > happening and everything hasn't been fixed, and so probably, hacking will keep > happening in the future also. Yes, but just arbitrarily imposing limits on inputs does not magically fix the bugs. Sadly, each of these bugs require finding the root cause and fixing *that*. > > If we take care of the minority, then the majority will have to put in > effort to validate the > inputs before calling insecure functions Or the maintainers of the implementations of those functions need to check them to see whether they contain bugs that make them insecure, and then fix the bugs. > Currently there is no maximization. POSIX/glibc functions don't > validate the inputs at all. There are no such limits to validate, so they can't "validate" inputs that have no limits against which to check. > Same is the problem with PHP/Javascript code. In many of those cases - possibly most if not all of them - the limitations against which they weren't validating input weren't length limitations, they're more subtle limits on the *contents* of the input. I'm not sufficiently familiar with PHP to know whether it has strings as first-class data types (without the string operations having the possibility of buffer overflow) and other language capabilities to detect potential buffer overflows and either report an error or grow the buffer as necessary, but I think Javascript has the former and may have the latter. Heck, I think some of the types in the C++ standard library have *that*. > Maybe the same problem is with the Python code too. Another language with the features I mentioned above, and in which the bugs are probably the lack of *content* validation (or doing bogus things such as using arbitrary strings from an outside source in as format strings or in some other context in which the content of the strings is interpreted in a way that can cause somewhat arbitrary actions to be performed - that may have been the cause of the log4j vulnerability). > However, the C language itself has no issues. [Citation needed] You *can* write safe code in C, it's just more of a pain because the compiler and language environment don't, for example, handle allocation for string buffers. > The main issue is that people who write code in C or in other languages, they > don't validate the inputs. One of the main problems is that people who write code in C don't bother to dynamically allocate buffers and don't check whether they're overflowing the buffer (which may be more complicated than individually validating sizes of the inputs), or *do* dynamically allocate them but don't do it correctly. There are other problems as well. > I have seen lots of different code in different languages over my 25 > years of career, and I see that software > engineers just don't have the habit of validating the inputs. I have seen lots of different code in different languages over my 38 years of programming as a career and 12 years of programming as aa free-software developer, and I see that there are a number of problems, but that the failure to impose arbitrary limits on string and other data sizes is *not* one of them.
