replacing MIT's ASN.1 code

[JC Ferguson]

Supporting two API's for ASN.1 encoding is an interesting idea.
I haven't looked closely at how the current ASN.1 is abstracted
to the callers.  To do this, you'd have to insert a 'shim' between 
the callers of the ASN.1 stuff and the actual ASN.1 implementation.  
Then, as you suggest, ./configure --use-new-asn1 or some such 
and you get the new implementation.

I understand the dilemma here - spend now to save later or amortize
the cost of adding new ASN.1 support to the existing implementation
over time.  Question is, when do you "break even".

A difficult decision.  But, if the ASN.1 implementation is abstracted
in a manner described in the first paragraph, perhaps a test program
could be written to validate the implementation prior to throwing
the 'big switch' ?

/jc
 

> -----Original Message-----
> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] 
> On Behalf Of Ken Raeburn
> Sent: Monday, October 15, 2007 17:51
> To: Kerberos developers list
> Subject: Re: replacing MIT's ASN.1 code
> 
> 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
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>