replacing MIT's ASN.1 code
jc at f5.com
Mon Oct 15 20:45:56 EDT 2007
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' ?
> -----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.
> krbdev mailing list krbdev at mit.edu
More information about the krbdev