Kees Cook <kees <at> debian.org> writes: > On Sat, Sep 21, 2013 at 02:46:34PM +0200, Bas Wijnen wrote: > > On Fri, Sep 20, 2013 at 10:12:16PM -0700, Kees Cook wrote: > > > This is absolutely a bug in glibc. While the spec can say "undefined", it > > > is, in fact, not undefined. It worked in a very specific way for over a
Right, “common law”. It predates the standard. > > > decade, so that's pretty well defined. ;) The fortify function has no need > > > to change it. > > > > I strongly disagree. If I write a specification for something and an > > implementation of it, then the specification is what defines the behavior. If But you don’t just write a C99 library! You write a libc for a Unix-ish system, with POSIX coming into the mix… as well as lots of historic practice! Using the standard not defining something as excuse to break historic practice just makes you look bad. > > Code that does undefined things is buggy, even if it works on some > > implementation, and no matter how long it has worked. I totally disagree. Yes, the C99 standard has a lot of Undefined Behaviour, more than C89 anyway – but why? > it's a bug to even allow undefined behavior. I’m calling for a language that is enough like C for us to be able to reuse existing code, but has no UB, defines signed overflow, defines bit sizes (no more 36-bit ints), etc. I think you’d like that too, from a security PoV. The idea that there were conflicts in the standards committee is not all that off, or maybe they just couldn’t decide or didn’t want to or, like GCC developers (who said this publicly!) only care about benchmark performance because relying on UB enables some otherwise-unsafe optimisations. But it’s a nightmare and prevents people from both writing reliable code now *and* using old code (say, AT&T nroff, from decades back) with modern (other than tcc and pcc) compilers. > In a theoretical sense, sure. In this particular case, why bother breaking > it when it's a trivial 1 line fix? My original approach was to fix it in > libc and do a mass bug filing. Everyone wins. If we want to reject the The glibc people decision to return NULL in crypt(3) has led to several (plural) CVEs in other software, such as cyrus-sasl2 and xlockmore, already and breaks the GNU CVS testsuite. I’ve watched them (both upstream and Debian) not care. (FWIW, musl never returns NULL, and MirBSD libc now also doesn’t, even not in the very obscure cases where it was historically acceptable, especially since even the “how to use crypt()” example in POSIX itself happily dereferences the retval w/o NULL checks.) I’m with you here, but I think you’re shouting at walls. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130924t134453-...@post.gmane.org