Dan Fandrich wrote: Hi Dan,
> 138KB. Yup. Any chance of splitting it into at least two parts, the OS400 stuff and everything else? Yes! I sent it as a whole for a "preview". If I've sent generic code alone, one might have asked why is it for since it is not called by non-OS400 parts right now :-) The only big OS400 part you have in this patch is "gskit.c". Others are just details. In addition, qssl.c and gskit.c may serve as generic part use examples. But you're right, I'll commit in parts... > I'm a bit hesitant about this part. It seems that more and more X.509/TLS stuff is slowly finding its way into curl itself. > The ASN.1 code especially seems to me to be the kind of thing that should be in a cross-platform library of some sort > that curl can depend on instead. The problem now is we already rely on external libraries that are not compatible together. In particular, there are things that are supported by one library, but not others, like certinfo. As a consequence, one have to reinvent the wheel each time a new SSL backend is implemented, thus multiplying the risk of bug by the SSL backend count, or not implementing at all like certinfo is until now. The idea is not to rewrite a full backend, but rather to have some very simple primitives able to extract some info from certificates. > That kind of parsing code is the kind that's hard to get completely right from a security standpoint. As stated above, the responsibility of certificate syntax validation is left to the real SSL backend. The x509asn1.c code should not be applied to a certificate that has not been validated by a "serious" backend. The only sensible part is the "verifyhost" feature, that did not need a local parser to "implement" a security weakness (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0037). Thanks for your comments, Patrick ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
