27 ms·
> am i the only one that thinks this is a total non-issue? OpenBSD's slogan boasts that there have only ever been "two remote holes in the default install", on
by glass- 12y ago
> am i the only one that thinks this is a total non-issue?
OpenBSD's slogan boasts that there have only ever been "two remote holes in the default install", one of those holes would have been prevented by this.
- foxhill 12y agowhilst i appreciate the prudence of this measure, it doesn't do anything for existing programs. this will not fix any codes in OpenBSD that currently ship with it.
- tedunangst 12y agoIf only there were some way to modify those programs to use this function...
- foxhill 12y agoeither you mean intercepting malloc/realloc calls, in which case can't happen as the function signature is different, or you mean literally modifying the source code of existing programs, and releasing that. which, lets face it, in the BSD is space (and particularly with regard to memory allocations from user input), is highly unlikely to change any time soon.
- clarry 12y ago> or you mean literally modifying the source code of existing programs, and releasing that. > > which, lets face it, in the BSD is space (and particularly with regard to memory allocations from user input), is highly unlikely to change any time soon. I'm not sure how to parse your sentence. Are you saying OpenBSD (which should be known for its mass audits) isn't likely to make changes in its source code any soon? http://freshbsd.org/search?q=reallocarray http://freshbsd.org/search?q=reallocarray