Ben Laurie wrote: > gets is so not the problem. Using strings that _can_ overflow is the > problem. That means wrapping the entire standard library. > > And, of course, the issue is that every other library in the universe > uses C-style strings (etc.), so unless we can all agree on a better > paradigm, we're screwed.
note that various infrastructures ... have made the length field an integral characteristic of nearly every piece of storage and that automatic use the length values an integral piece of every operation; extended from the lowest level interrupt handlers and device drivers ... up thru the most complex application code. it isn't just a characteristic of the high level application libraries ... but nearly every aspect of the operation environment. these length-based paradigms aren't only limited to programming languages (other than C) ... but can also be found in infrastructures that are pure assembler code. the other way of viewing the string issue is that the length isn't explicit ... the default c-based length paradigm is implicit based on the pattern of data in a buffer ... which tends to create length related vulnerabilities from simple data manipulation operations (you might generalize this as a dual-use vulnerability). this is further compounded when there is a field/buffer that is empty and doesn't yet have any data to establish an implicit data-pattern defined length. explicitly separating the length attribute from any data pattern characteristic would make the infrastructure less vulnerable to length mistakes resulting from simple data manipulation operations. it would also enable a single, consistant length paradigm for both field/buffers that contain data patterns and field/buffers that are empty and don't contain data patterns. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]