replacing MIT's ASN.1 code

[Ken Raeburn]

On Oct 15, 2007, at 17:38, JC Ferguson wrote:
> My big concern would be quality.  As you state below,
> the MIT ASN.1 implementation has been kicked around
> for years, is solid, interops with MSFT and others.

Much of it.  The LDAP database back end and PKINIT have both  
introduced new code.

The advantage I see to the A2C implementation is that buffer length  
checks and such are done once in the support code; adding new types  
introduces much less of an opportunity to add new bugs.  With the MIT  
code, on the other hand, adding a new type means reading through the  
processing for other types, hoping you understand all the multiple  
levels of macros well enough to copy what they're doing and modify it  
correctly, and writing new C code.

I suppose one approach might be to ship both ASN.1 implementations  
for a while, so the more daring users can help us shake the bugs out  
while more conservative ones use the old, more tested code, and then  
we switch the defaults and eventually purge the old version (assuming  
the new one proves solid enough).  I'm not crazy about supporting two  
ASN.1 runtimes, and I can certainly imagine people writing patches  
that add new ASN.1 types and say "oh, but this only works if you  
enable A2C", kind of leaving us screwed if we decide not to make the  
switch.  But with the discipline to refuse the latter patches in the  
main sources, it might be one way to make the switch over the course  
of a year or two.

Ken