Issue with v1.1.1 in CentOS 8 regarding OPENSSL_CONF

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue with v1.1.1 in CentOS 8 regarding OPENSSL_CONF

Michael Stemle, Jr
Hello!

I’ve been troubleshooting an issue with OpenSSL in a dependency of a Perl module I maintain. It looks like the rabbitmq-c library that the module uses implemented CONF_modules_load_file(), but it seems to be causing problems and I’m not sure how to address it properly. 

Here’s the bug on my module as reported by the CPAN testers: https://github.com/net-amqp-rabbitmq/net-amqp-rabbitmq/issues/186

Here’s an issue I raised and have been troubleshooting with the C library which implements rabbitmq: https://github.com/alanxz/rabbitmq-c/issues/602#issuecomment-594987398

I’m not quite sure what the right path forward is here, and I would greatly appreciate some advice.

Many thanks. 

~ Michael D. Stemle, Jr.
Reply | Threaded
Open this post in threaded view
|

Re: Issue with v1.1.1 in CentOS 8 regarding OPENSSL_CONF

Viktor Dukhovni
On Thu, Mar 05, 2020 at 08:08:42PM -0500, Michael Stemle, Jr wrote:

> <BOM-found-here>Hello!

For some reason your email client included a UTF-8 BOM at the start of
the message text.  Best to not do that.

> I’ve been troubleshooting an issue with OpenSSL in a dependency of a
> Perl module I maintain. It looks like the rabbitmq-c library that the
> module uses implemented CONF_modules_load_file(), but it seems to be
> causing problems and I’m not sure how to address it properly.

What does "implemented" mean?

> Here’s the bug on my module as reported by the CPAN testers:
> https://github.com/net-amqp-rabbitmq/net-amqp-rabbitmq/issues/186

I added a comment:

    https://github.com/net-amqp-rabbitmq/net-amqp-rabbitmq/issues/186#issuecomment-595579659

> Here’s an issue I raised and have been troubleshooting with the C
> library which implements rabbitmq:
> https://github.com/alanxz/rabbitmq-c/issues/602#issuecomment-594987398
>
> I’m not quite sure what the right path forward is here, and I would greatly appreciate some advice.

With OpenSSL 1.1.1b and forward the correct way to initialize the SSL
library with a custom application name "appname" (from some code slated
to some day be integrated into Postfix) is:

#if OPENSSL_VERSION_NUMBER >= 0x1010102fL
    OPENSSL_INIT_SETTINGS *init_settings = NULL;
    unsigned long init_opts = 0;
    unsigned long init_flags = CONF_MFLAGS_IGNORE_MISSING_FILE;

    if ((init_settings = OPENSSL_INIT_new()) == 0) {
        /* error */
        ...
    }

    OPENSSL_INIT_set_config_appname(init_settings, "appname");
    /*
     * By not including CONF_MFLAGS_IGNORE_RETURN_CODES, we get strict error
     * reporting.  We don't insist on a match for the requested application
     * name, allowing fallback to the default application name, even when a
     * non-default application name is specified by always setting the
     * CONF_MFLAGS_DEFAULT_SECTION bit.
    */
    init_flags |= CONF_MFLAGS_DEFAULT_SECTION;
    OPENSSL_INIT_set_config_file_flags(init_settings, init_flags);

    if (OPENSSL_init_ssl(init_opts, init_settings) <= 0) {
        /* error */
        ...
    }
#endif

I don't recall whether/when it may be appropriate to call
CONF_module_load_file().  That may have to be done after the library is
initialized.

I still don't know what all those looping libraries were, none of the
sort are present on my system.

--
    Viktor.