|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Fwd: [e-lang] Protocol implementation errors
Rich Salz wrote: > > Are you saying it doesn't make sense to ask why ASN.1 has been > > vulnerable to long-lived bugs? We are not talking about just one > > bug in just one implementation. > > In every case so far, it's been untested code paths. As others have > said, that's not ASN1/[BDPX]ER's fault. Hm. Seems to me that untested code paths are at least _partly_ ASN.1's fault. You've got the BER, DER, PER, and XER, all of which perform essentially the same function in different ways. That right there gives you four times as much code to verify and test. I'm not familiar with [DPX]ER, but the BER is a tag-length-value scheme with variable length tags (!), variable length length fields (!!), and two different ways of encoding the length (!!!) There are eight different ways to encode floating point numbers. The IMPLICIT keyword, which causes the tag part of the TLV triple to be omitted from the presentation stream, means that you can't just build and verify a generic BER decoder; in the worst case you have to build, and verify, separate decoding routines for every complex data type known to the system. The list goes on. Given the number of options, ASN.1 inherently requires a lot of code to implement, with a lot of code paths that are never exercised in production. Devising a test suite for a code base with that much surface area has got to be a Herculean task. It's not surprising that bugs have been found in untested code paths; I'd be very surprised if there *weren't* any. --Joe English jenglish@f...
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








