On Sat, 31 Jan 2026 at 21:51, David A. Wheeler via austin-group-l at The Open Group <[email protected]> wrote: > > On Jan 31, 2026, at 2:37 AM, Amit via austin-group-l at The Open Group > > <[email protected]> wrote: > > If there are appropriate mechanisms to improve software security at this > level that would > be of great interest to me. However, you'll need to find > specific examples that *this* group addresses, and show that the given > inputs are *NEVER* valid (or that the added more-complex control is worth > adding). > > > About limits on the inputs: Let's say that there is a sorting function > > that sorts an integer array, and it takes the number of array elements > > as an input. In this case, you can limit the maximum number of > > elements to around 10% of the RAM size and the total size of the > > array to around 25% of the RAM size. > > I don't agree with this example at all. > *YOU* might not have large datasets, but many other users *DO* have large > datasets. > Why is everyone forbidden to use 75-90% of our RAM when sorting? > This would destroy availability, which is *also* part of the definition of > security. >
I came to this group mainly for the POSIX standard. We cannot put a hard limit on many inputs and that's why I came up with this percentage of RAM size idea. I just gave an example of 20% of the RAM size but if someone wants to use 75% of the RAM size, even then it should be okay. But the idea is to have some practical limit on the inputs. Already in UNIX/LInux, you can't give an input of more than 4096 characters on the terminal (I have tested this). Also, there are limits on the maximum length of a file name, etc. There are more limits like these in UNIX/Linux. So, there are already examples of what I am proposing. I can't think of any input that is always invalid. It depends on the function. For some functions, even NULL may be a valid value. In my opinion, denial of service is better than getting hacked. In DoS, no personal information is leaked. But if someone gets hacked then his/her personal information can be leaked. In my opinion, we can't get both - availability of service and also practical limits on the inputs. We need to leave something out. I believe that something is better than nothing. I am in favor of leaving the availability of service out, and I think that denial of service will not affect anyone else other than the user - for example, if someone wants to sort 100 billion elements and if we are not supporting that, then that user won't get service. But the action of this user is not going to result in DoS for other users. But obviously, there are lots of DoS out there and many of them are related to exhausting the data networking pipeline and not directly related to validating the inputs - like TCP SYN attack, etc. But those can also be mitigated by blocking the offending IP address(es). > > The most important part of creating secure software is to validate all the > > inputs of all the functions. > > It's certainly important to validate inputs for security! But that requires > that you > know what the valid inputs *are*. > Inputs to pointers should not be NULL. But most of the inputs in POSIX/glibc are dynamic, we can't put a hard limit, and that's why I came up with this percentage of RAM idea. But even then, we can put limits at the application level - like, name of a person - we can limit this to 50 characters. If someone's name is more than 50 characters then we can't provide service to that person. But in general, no one will have a name of more than 50 characters. We can also put a limit on the maximum length of a URL, maybe like, 1024 or 2048 characters. I don't think that in general URLs will have more than 1024 characters. Already in UNIX/LInux, you can't give an input of more than 4096 characters on the terminal (I have tested this). Also, there are limits on the maximum length of a file name, etc. There are more limits like these in UNIX/Linux. So, there are already examples of what I am proposing. I believe that I don't want to satisfy a minority of users at the expense of the majority of users in the matters of software security. > I suggest looking for strong specific proposals relevant to this group. E.g.: > > 1. Cases where it's obvious that certain inputs should *never*.be allowed, > especially if it's not hard to detect during processing. I can't think of any input that is always invalid. It depends on the function. For some functions, even NULL may be a valid value. > 2. Cases where inputs are currently undefined but should be clearly defined > or defined to have limited options to prevent undefined behavior. POSIX/glibc is an example where there are no limits on the inputs. > 3. Mechanisms that would make it easier, more generally, to perform > application-specific validation. Improvements to regex come to mind here. I didn't understand this point completely. In my opinion, POSIX/glibc should be made secure. If not, then people will have to validate the inputs before calling POSIX functions. But then there are thousands of developers using glibc, so thousands of man hours will be gone in doing this. If it is done at the POSIX/glibc level then the developers can save their time and focus on something else. Amit
