1. 26

Jonas ‘Sortie’ Termansen the author of sortix operating system gives feedback to the gnulib team.

  1.  

  2. 9

    The reply is amusing

    We look at things a different way. Buffer overflows are easily caught by widely-available tools, and if remote code execution is a problem then one ought to be using such tools.

    Remote code execution is always a problem. As a rough benchmark, there are 12259 CVEs with the keyword ‘overflow’, and there are only 86 CVEs with the keyword ‘truncation’. I think this is also a framing difference. The response is relying on bug detection whereas the original post is relying on damage scope. The ability to detect a truncation is difficult, yes, but the damage scope is relatively low. Conversely, while tools exist to detect a buffer overflow, the damage scope is so many orders of magnitude higher that it is worse in the long run if the tools fail to detect a buffer overflow.

    there’s a lot to say for the GNU tradition of refusing to impose arbitrary limits (as snprintf-using code usually does)

    Uh, is there? Are there any strong arguments for refusing to impose arbitrary limits that can’t be disarmed by “make resizing and retrying fundamentally easier” ?

    Off topic, I just noticed that Termansen was 2 years younger than me when he started writing sortix, dang.

    1. 6

      The reply is an usual GNU/Frredesktop/RH attitude of “RESOLVED WONTFIX” for every time someone out of the “herd” has a serious suggestion or criticism of fundamental aspects of the software they develop.

      1. 5

        You’ll have better success with a calm rationale and a diff than a rant without one.

        I used to complain about certain projects but I’ve since been able to get diffs into them. I avoided complaining to people’s faces and stayed maximally professional, and just did the thing they want (and pinged my patches every 2-4 weeks when they were ignored).

        1. 3

          Add Mozilla and Google to that list :(