HiveExt.dll needs an update and recompile for MySQL 8.0.28+

[ndavalos]

Someone needs to recompile hive so that it can use a more modern TLS version. TLS 1 and TLS 1.1 were deprecated years ago due to flaws in the encryption and finally removed from MySQL 8 in version 8.0.28. MySQL native password authentication is also deprecated and slated to be removed altogether at some point. Basically, just need to upgrade hive to support TLS 1.2.

https://dev.mysql.com/doc/refman/8.0/en/encrypted-connection-protocols-ciphers.html

For now, there are a few workarounds for new installs using MySQL 8 (which is listed in the server install instructions)

1. Enable MySQL native authentication by editing my.ini and setting: authentication_policy=mysql_native_password,, This will unfortunately stop working as well since MySQL native authentication is deprecated and slated for removal at some point

2. Install MySQL 8.0.27 (not recommended to stay on old versions): https://downloads.mysql.com/archives/community/

3. Install mariadb, this is basically the MySQL code base at version 5.7, which still supports legacy authentication methods, this is a go-to for most people that have legacy apps that cant's or won't stay up to date with the latest MySQL releases. I have not tried using hive with mariadb, but it should work regardless (I've encountered MySQL compatibility issues with activerecord for ruby on rails and using mariadb instead fixed most issues): https://mariadb.org/download/?t=mariadb&p=mariadb&r=10.9.2&os=windows&cpu=x86_64&pkg=msi&m=acorn

I just discovered this when I tried migrating my servers to a new box with a fresh install of MySQL 8. I've been working on a replacement for hive that doesn't require .NET, C++ runtimes or the MySQL library, but I won't have that done for quite some time due to other commitments.

[IsGoose]

I second this, it would also open up a massive QOL opportunity by adding the ability for server owners to add custom DB Queries native to Hive without the need for 3rd party Extensions like ExtDB, just an idea

[ndavalos]

I second this, it would also open up a massive QOL opportunity by adding the ability for server owners to add custom DB Queries native to Hive without the need for 3rd party Extensions like ExtDB, just an idea

I actually wrote a dll that works the same way as extDB2 but doesn't require a client library or C++ runtimes. It natively connects to MySQL instead of requiring libmysql.dll. My plan was to add the functions that are in HiveExt to it so it could simply just replace HiveExt and have the ability to extend the database however you want. I just haven't gotten around to recreating the HiveExt functions in it.

[icomrade]

I rebuilt this with MySQL 5.7.40 icomrade/icomradeHiveEpoch@dc3973e3899d58cfeb1bf0df8b4e3be6ddd8414f

EDIT: Please ignore the linked binaries, they will not work as anticipated

there's a binaries.zip file on the repo that contains the updated binaries. I have not tested these as I no longer have a ArmA test server up

unfortunately there's no x86 support on 8.0+ versions of mysql so rebuilding libraries with that version is not an option and 5.7 is limited to TLSv1.2

[icomrade]

Please try icomrade/icomradeHiveEpoch@0cfa1497a237a1266970ae14df9807c362db8a8f

I also setup a test server and it appears to work with the latest version of MySQL community at the time of writing (8.0.31) with 'Strong Password Encryption for Authentication' enabled from the installer.

[AirwavesMan]

Please try icomrade/icomradeHiveEpoch@0cfa149

I also setup a test server and it appears to work with the latest version of MySQL community at the time of writing (8.0.31) with 'Strong Password Encryption for Authentication' enabled from the installer.

Ive got no problems so far. The files running on my live server now. I will report back in about one week.

For everyone else who is willing to test this. Please download those files, add them to your server an report any problems with it here. https://github.com/icomrade/icomradeHiveEpoch/blob/master/Binaries.zip

[vlaben]

Hello to everyone,

@icomrade,

I would like to point to original design issue with possible fatal impact:

• Main HiveExt controller is unique_ptr gApp which is Global object
• Main HiveExt controller gApp shutdown function is defined as unique_ptr reset to nullptr
• Shutdown function is used in DllMain entrypoint on DLL_PROCESS_DETACH

Problem:

• On DLL_PROCESS_DETACH, there is no check for if (lpReserved != nullptr), which leads to shutdown function call (gApp.reset();) - no matter what.
• if (lpReserved != nullptr) is true, global objects (incl. gApp) no longer exists, and making that call will raise runtime error and server crash (if you would store memory address of gApp at the app start and read value at the beginning of DLL_PROCESS_DETACH scope, you would get correct address, but since heap is already in inconsistent state (OS is reclaiming memory), further pointer manipulation will crash Arma with famous catched error from runtime Exception code: C0000005 ACCESS_VIOLATION at XXXXXXXX in RPT and crash dumps. Of course, this is just 1 specific case...)

Solution:

• DllMain->DLL_PROCESS_DETACH can be written:

  case DLL_PROCESS_DETACH:
  {
    if (lpReserved != nullptr)
    {
        // Raymond Chen : The building is being demolished. You don't need to sweep the floors.
        break;
    }
  
    // Perform any necessary cleanup.
    ExtStartup::ProcessShutdown();
    break;
  }

...and some of these unexplained server crashes that has been mentioned in community should be gone...

[icomrade]

Thank you for the reply and write up. I've implemented your suggestion in the commit above this comment and rebuilt the binaries

Edit: again only briefly tested the changes made in the commit, so if anyone is interested in testing please try it out in your environments

[AirwavesMan]

Ive tested the new hive on different systems with MySQL 5.7 and 8.0.30 and everything works so far. If nobdy has different experiences I will update the server package for Epoch with the new files and a few fixes.

[vlaben]

Hello to everyone,

@icomrade,

before @AirwavesMan uploads new binaries to Epoch repo, please consider ExtStartup::ProcessShutdown() following change:

// https://github.com/icomrade/icomradeHiveEpoch/blob/master/Hive/Source/HiveLib/ExtStartup.cpp#LL126-L129C2
void ExtStartup::ProcessShutdown()
{
    // Gracefully close [root/AsyncChannel] to prevent application hang and crash on exit.
    Poco::Logger::root().getChannel()->close();
    Poco::Logger::shutdown();

    gApp.reset();
}

There are multiple reasons, why it should be considered - just naming a few:

• It is safe, even if Hive is not in state with async logging enabled - Poco::Channel base class virtual method close() default implementation does nothing, if that is the case (meaning on error state).

• Most of the time, Hive uses Poco async logging facility - it's enabled at Logger::root() global level via Poco::SplitterChannel (see source here and here).

• It's async - simply put - worker thread is spawn for FIFO message queue - if it is not closed properly before exit, all queued messages are lost and especially on Windows, application can hang (if you develop Epoch and restart frequently, I bet you have already experienced strange application hang followed by another unexplained-hard to track-crash). This problem is well known on Windows - see for example popular logging library spdlog : Windows issues.

[ndavalos]

• It's async - simply put - worker thread is spawn for FIFO message queue - if it is not closed properly before exit, all queued messages are lost and especially on Windows, application can hang (if you develop Epoch and restart frequently, I bet you have already experienced strange application hang followed by another unexplained-hard to track-crash). This problem is well known on Windows - see for example popular logging library spdlog : Windows issues.

...and another hard to explain behaviour on application exit should be gone...

EDIT: Added more detailed comment to fix for ExtStartup::ProcessShutdown()

That might explain why my tavi server crashes on shutdown every time. None of the others do, just that one for some reason and I've never been able to track it down.

[icomrade]

Hello to everyone,

@icomrade,

before @AirwavesMan uploads new binaries to Epoch repo, please consider ExtStartup::ProcessShutdown() following change:

// https://github.com/icomrade/icomradeHiveEpoch/blob/master/Hive/Source/HiveLib/ExtStartup.cpp#LL126-L129C2
void ExtStartup::ProcessShutdown()
{
    // Gracefully close [root/AsyncChannel] to prevent application hang and crash on exit.
    Poco::Logger::root().getChannel()->close();
    Poco::Logger::shutdown();

    gApp.reset();
}

There are multiple reasons, why it should be considered - just naming a few:

• It is safe, even if Hive is not in state with async logging enabled - Poco::Channel base class virtual method close() default implementation does nothing, if that is the case (meaning on error state).
• Most of the time, Hive uses Poco async logging facility - it's enabled at Logger::root() global level via Poco::SplitterChannel (see source here and here).
• It's async - simply put - worker thread is spawn for FIFO message queue - if it is not closed properly before exit, all queued messages are lost and especially on Windows, application can hang (if you develop Epoch and restart frequently, I bet you have already experienced strange application hang followed by another unexplained-hard to track-crash). This problem is well known on Windows - see for example popular logging library spdlog : Windows issues.

Thanks again for the write up and suggestion. I have implemented this and recompiled the binaries

[AirwavesMan]

From my experience the new hive is stable. I will update it to a new Server Package.

[AirwavesMan]

Epoch 1.0.7.1 files got updated with the newest hive.dll