[
Lists Home |
Date Index |
Thread Index
]
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/
|
