On Sat, Feb 14, 2015, Benny Baumann wrote: > > I want to encode a new CRL's (X509_CRL_new), currently invalid, > Signing algorithm (i2d_X509_ALGOR( crl->siging_alg, ... ) ) and > restore that with "d2i_X509_ALGOR( &crl->signing_alg, ...)" > afterwards. Restoring of the algorithm works fine in OpenSSL > 1.0.1.f, but fails in OpenSSL 1.0.1j and 1.0.1l. This is probably > because the "i2d" function encodes the (invalid) Signing algorithms > slightly different in the different versions. This happens, because > the invalid signing algorithm is represented slightly different in > the internal structure. > In version 1.0.1f the invalid algorithm is encoded as sequence with > an object id with length 1 and content "00" ( -> 30 03 06 01 00). In > the newer versions (1.0.1j and 1.0.1l) the invalid algorithm gets > encoded as sequence with an object id of length 0 ( -> 30 02 06 00). > This new encoding causes the "d2i" function to fail. Now the "d2i" > function nulls the "sig_alg". This causes a "X509_CRL_verify" to > cause a segfault. > > Is this behavior expected? Am I doing something wrong? Is there a > problem with what "X509_CRL_new" does (setting different > "UNDEFINED"-ObjectId-Objects)? > For better clarifying my problem, I have attached a small example > code that creates such a CRL, tries to verify it (what will fail, > but not crash), does the i2d, d2i re-setting of the Algorithm and > re-calls X509_CRL_verify which now crashes in 1.0.1j and 1.0.1l, but > works fine in 1.0.1.f. > Arguably the bug is in the i2d functions which should refuse to encode a structure which hasn't been properly initialised. If you set the algorithm OID to a valid value (which you can change later) this should work in all versions of OpenSSL. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org
