replacing MIT's ASN.1 code
raeburn at MIT.EDU
Mon Oct 15 17:50:43 EDT 2007
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.
More information about the krbdev