maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Vladislav!

On May 20, Vladislav Vaintroub wrote:
> 
> >> --- a/include/sslopt-case.h
> >> +++ b/include/sslopt-case.h
> >> @@ -29,8 +29,8 @@
> >>        One can disable SSL later by using --skip-ssl or --ssl=0
> >>      */
> >>        opt_use_ssl= 1;
> >> -    /* crl has no effect in yaSSL */
> >> -#ifdef HAVE_YASSL
> >> +#ifdef HAVE_WOLFSSL
> >> +      /* CRL does not work with WolfSSL */
> >
> >Still?
> 
> It does not work the way we need it to.  There seems to be some CRL
> functionality, however X509_STORE_load_locations() is implemented as
> stub function that does nothing .

There's wolfSSL_CertManagerLoadCRL(), which, supposedly
loads a certificate from a file. There's no functionality, as far as I
can see, to load a whole directory of crls.

> With that,  we’ll get an unresolved symbol for
> WolfSSL_X509_STORE_load_locations. I’m not sure whether and how we can
> live without X509_STORE_load_locations().

Okay. If needed we could implement X509_STORE_load_locations for WolfSSL
(like I had yassl.cc with missing functionality). I guess, just
iterating all files in a dir and calling wolfSSL_CertManagerLoadCRL()
for every file should do it.

Probably not now, because "replacing yassl" only means "provide at least
the functionality that yassl had".

> >>    virtual int finish(uchar *dst, uint *dlen)
> >>    {
> >> +#ifdef HAVE_WOLFSSL
> >> +     /*
> >> +       Bug in WolfSSL - sometimes EVP_CipherFinal_ex
> >> +       returns success without setting destination length
> >> +       when it should return error.
> >> +       We catch it by presetting invalid value for length,
> >> +       and checking if it has changed after the call.
> >> +
> >> +       See https://github.com/wolfSSL/wolfssl/issues/2092
> >> +     */
> >> +    *dlen= UINT_MAX;
> >> +#endif
> >
> >I suppose you can remove it. This is fixed as of 4.0.0-stable tag.
> 
> Can’t remove it just yet. They fixed a test case that I provided, but
> there was still failure in another corner case, for which I filed
> https://github.com/wolfSSL/wolfssl/issues/2224 , which is not fixed in
> 4.0.0-stable.

Update the comment to mention the new issue, please

> >> --- a/plugin/file_key_management/parser.cc
> >> +++ b/plugin/file_key_management/parser.cc
> >> @@ -103,7 +103,6 @@ openssl enc -aes-256-cbc -md sha1 -k "secret" -in keys.txt -out keys.enc
> >>      EVP_BytesToKey(EVP_aes_256_cbc(), EVP_sha1(), salt,
> >>                     secret, strlen(secret), 1, key, iv);
> >>
> >> -   but alas! we want to support yassl too
> >
> >does wolfssl have an equivalent of EVP_BytesToKey?
> >if not, the comment still holds.
> 
> Yes, they have EVP_BytesToKey now.

That means you can replace the whole Parser::bytes_to_key() body with
one EVP_BytesToKey(), right?

Regards,
Sergei
Chief Architect MariaDB
and security@xxxxxxxxxxx