On Fri, Feb 04, 2022 at 11:02:24PM +0500, Илья Шипицин wrote: > пт, 4 февр. 2022 г. в 19:16, William Lallemand <[email protected]>: > > > On Fri, Feb 04, 2022 at 11:52:06AM +0100, William Lallemand wrote: > > > > > > I just tried to build with the latest boringSSL version, the problem is > > > on our side: > > > > > > We are defining X509_OBJECT_get0_X509_CRL() because it does not exist in > > > boringSSL, and inside it we are accessing the members of the X509_OBJECT > > > and it can't work since it's opaque. > > > > > > We need to use the accessors instead, or find an alternative API. > > > > > > > So, basically, we need to extract some X509_CRL from an X509_STORE which > > could be done in OpenSSL with the X509_OBJECT API by using > > X509_OBJECT_get0_X509_CRL() which is not available in boringSSL > > > > We are kind of stuck there because this is supposed to be the low > > level API, now everything is opaque and we can't do much. > > > > The alternative would be to stop using the X509_STORE for storing the > > CRL, and use a STACK_OF(X509_CRL)... But we use the store because it > > could be either a X509_CRL or a X509... so it would be kind of > > redefining a X509_STORE API... and I honestly don't want to do that. > > > > In my opinion there is a problem in their API because there is no > > accessor for the X509_CRL in a X509_OBJECT. Which is kind of weird > > because they have a X509_OBJECT_get0_X509() accessor, they probably just > > missed it. > > > > we already use "#ifdef X509_V_FLAG_CRL_CHECK" for enabling those functions. > in theory we have 2 choices > > 1) adopt X509_OBJECT_get0_X509_CRL to BoringSSL in some way > 2) exclude CRL manipulations under BoringSSL by adjusting ifdef
I can't spend more time on this, feel free to open a bug report on their bugtracker, this is probably better for everyone. You can adjust the ifdef as well. -- William Lallemand
