[omniORB] SSL Transport and ORB_init

[Christopher Fahey]

Ok, thank you Duncan for that explanation.  What would be the procedure 
for creating a derived class from sslContext?  Would it look something 
like this?  Is there somewhere in the code that would prevent deleting 
the one created in the init?

                 class ChildSSLContext : public sslContext
                 {
                     public:
                         ChildSSLContext();
                         // access SSL_CTX and add a cert to it.
                         void addTrustedCert();
                         //  access SSL_CTX and go to 
verify_mode_incoming = 0 with callback for all certs.
                         void enableUntrustedSSLMode();
                     protected:
                         virtual void set_privatekey();  // alter 
behavior to trap and clean up.
                 }
                 omni::sslContext::certificate_authority_file = 
config.sslConf.publicCertFile.c_str();
                 omni::sslContext::key_file = 
config.sslConf.pfxFile.c_str();
                 omni::sslContext::key_file_password = 
config.sslConf.password.c_str();
                 // create the corba object that will handle the requests.
                 orb = CORBA::ORB_init( cmdLine.argc, cmdLine.argv, 
"omniORB4" );
                 // get copy of existing singleton to delete when new 
one is created.
                 sslContext* ptr = omni::sslContext::singleton;
                 ChildSSLContext* repl = new ChildSSLContext();
                 repl->reinit( true );
                 omni::sslContext::singleton = repl;
                 delete ptr;

Thanks,

Christopher Fahey

On 11/1/2024 6:02 AM, Duncan Grisby wrote:
> On Wed, 2024-10-30 at 17:36 -0400, Christopher Fahey via omniORB-list
> wrote:
>
> [...]
>
>> All of this code works fine the first time through.  The problem is
>> the next time through. The user is prompted for the password a
>> subsequent time and when it comes through the key and password are
>> updated.  So far so good.  However, the orb was not completely
>> initialized the first time and the second pass encounters an
>> ASSERTION in the omni_giopStreamInitializer.attach() function because
>> it was previously called during the ORB_init but during the previous
>> pass and thrown exception, it didn't clean anything out when it
>> happened, leaving memory still in place.
> It is a bug that the failed ORB_init leaves it in a broken state. I'm
> surprised that has not come up before. It should be easy enough to fix
> it -- I'll look into it.
>
> However, for what you are trying to do, I think there is a better way
> to handle it anyway, because catching the INITIALIZE exception, you
> can't be certain that the cause of it was an incorrect password. What I
> suggest you do is make a subclass of the sslContext class, and override
> the set_privatekey method. It is designed to be overridden that way.
>
> In your overridden method, you can prompt the user for the password,
> and then if it is wrong, you will get the direct error from OpenSSL so
> you can be certain that the password is the problem.
>
> Look in include/omniORB4/sslContext.h for the class definition and in
> src/lib/omniORB/orbcore/ssl/sslContext.cc for the implementation that
> you should override.
>
> Regards,
>
> Duncan.
>