Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Friday 03 October 2003 15:49, Miles Sabin wrote: > Tyler Close wrote, > > > On Friday 03 October 2003 15:06, Rich Salz wrote: > > > In every case so far, it's been untested code paths. As others > > > have said, that's not ASN1/[BDPX]ER's fault. > > > > What if the design of ASN1/[BDPX]ER yields many more code paths > > than other designs? Is that a design flaw? > > Arguably it might be if that were the case. Is it tho'? Can you show > that the design of ASN1/[BDPX]ER is such that all plausible > implementations must have "many" more code paths than a plausible > implementation of a validating XML parser (or XML+WXS, or XML+RNG, or > XML+RNG+XSD)? That's not my job. I'm not the one proposing a change in implementation tools, the ASN.1 advocates are. We have data points to suggest that ASN.1 implementations may be difficult to test. I think this issue must be addressed by the ASN.1 advocates. They have to show it's no worse than the existing technology. > I'd be happy to be corrected, but _intutively_ I find > that somewhat implausible. I think the point I made in response to Simon St. Laurent is relevant here: On Friday 03 October 2003 13:15, Tyler Close wrote: > On Friday 03 October 2003 13:10, Simon St.Laurent wrote: > > In my explorations, ASN.1 toolkits felts more to me like data-binding > > kits than XML parsers. There doesn't seem to be much notion of anything > > like an "ASN.1 infoset", a set of containers and properties you can > > explore without necessarily knowing the bindings. ASN.1 feels > > effectively schema-driven, designed from the outset to be optimized for > > a world where processes are tightly bound. There aren't general ASN.1 > > "parsers" in the same sense that there are XML parsers, or at least > > there weren't last time I looked. > > This lack of layering might be a contributing factor to the > persistence of bugs in ASN.1. > > The merging of the "infoset" and the "schema" can be seen as > merging of the lexer and the parser. By complicating the lexer, > ASN.1 has made itself more vulnerable to bugs commonly associated > with a lexer, such as buffer overflow. Rich Saltz also made this point, though less directly: On Friday 03 October 2003 14:56, Rich Salz wrote: > In my experience, fixing "too long" errors for XML parsers has to happen > in only one place. Fixing them for ASN.1/[BDP]ER parsers requires > fixing it every time you nest a structure or list This is the implementation and testing impact of merging the lexer and parser. On Friday 03 October 2003 15:49, Miles Sabin wrote: > Personally, based on a mild acquaintance with with the OpenSSL source, I > think the bulk of the responsibility for the recent and not so recent > OpenSSL flaws lies neither with the design of ASN1/[BDPX]ER, nor with > sloppy coders, but with a large and by now somewhat crufty legacy > codebase. Everybody gets crufty eventually. The design must cope with that. Tyler -- The union of REST and capability-based security: http://www.waterken.com/dev/Web/
|
