[
Lists Home |
Date Index |
Thread Index
]
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@flightlab.com
|
