Critical Hotfixes

The major version of OpenSSL the Jade Platform uses (for TcpIpConnection class and Application Server to Thin Client encryption) is no longer supported by the OpenSSL Project. This hotfix updates OpenSSL to 3.0.8, which is currently the latest supported version.

There should be no effect to the majority of systems.  You will be able to apply the hotfix as normal; however there are some cases where changes may need to be made:

You are using a certificate that has a weak unsupported cipher
This would be likely only if you use old self-signed certificates, in which case you would have to regenerate the certificate.  The new certificate will work for Jade without the hotfix so you will be able to test the new certificate before hotfix installation if you require one.
  
You have configured Jade to use ciphers that are no longer supported
You will have to edit this custom configuration as there is no way to enable unsupported weak ciphers.  The jommsg log will display the name of the unsupported cipher you are attempting to use.
An example of this configuration would be the SSLCipherNames option in the jade.ini file that can be set to "<default>" for maximum compatibility.

You have defined external functions to ssleay32.dll or libeay32.dll
The names of these OpenSSL libraries have changed to libssl-3-x64.dll, libcrypto-3-x64.dll for 64bit and libssl-3.dll, libcrypto-3.dll for 32bit respectively, so you will have to change the library name for these definitions in Jade.

For these reasons, we strongly suggest you first test the hotfix installation (especially thin-client download) in a test environment with the same configuration (e.g certificate/ciphers) as the intended production environment.

Update 5 April 2023:
The extraction of encryption schema files has changed with this OpenSSL hotfix. 
Encrypted schemas extracted with the hotfix present will no longer load into systems not running the hotfix.
Encrypted schemas extracted without the hotfix will load into systems running the hotfix.
This does not affect other normal schema load version requirements.

e.g
Encrypted schema files, extracted with 22.0.01.022 and onwards will not load into earlier versions of 22.0.01 (e.g 22.0.01.021).
Encrypted schema files, extracted with 22.0.01.021 or ealier, are still able to be loaded into all versions of 22.0.01.
Unencrypted schema files are unaffected.

If you have any questions, please contact jadesupport@jadeworld.com

Prior to Jade 2020 SP1 Date and Time dictionary keys with an invalid Date or invalid Time value were sorted before valid Date or Time values. This was inconsistent with invalid Date or Time values in TimeStamp or TimeStampOffset keys. Invalid Date or Time values in a TimeStamp or TimeStampOffset key were sorted after valid Date or Time values.
This sort order was also inconsistent with the result of the comparison of an invalid Date or Time value with a valid Date or Time value. An invalid Date or Time value is greater than any valid time. In Jade 2020 SP1 invalid Date or Time values are now sorted after valid Date or Time values.

This change means that it may not be possible to read or remove entries by key in a dictionary that has invalid Date or Time key values.

Due to the change in the key handling any persistent dictionaries with an invalid Date or Time key values needs to be rebuilt to ensure the invalid Date and Time key values are sorted correctly. This applies to persistent instances of MemberKeyDict, ExtKeyDict and DynaDictionary.

Install the hotfix 20.0.02.024

The hotfix includes code to update any dictionaries with invalid Date or Time key values when a system is upgraded from Jade 2018 to 2020. If the system has already been upgraded to Jade 2020 SP1 a fixup method must be executed manually after applying the hotfix. The fix-up method `RootSchema::Schema::_fixDictionariesWithInvalidDateAndTimeKeyValues` iterates all persistent dictionaries with Date or Time keys scanning for invalid Date or Time values. Any dictionaries found with these key values are rebuilt. Output from the fixup script is written to the InvalidDateAndTimeKeys.log file in the Jade log directory.

Any Jade 20.0.02 systems with persistent dictionaries that have either invalid Date or Time key values.

The following is an example of running the fix-up method via command line:

> jadclient path=database-path ini=initialization-file-name app=RootSchemaApp schema=RootSchema executeSchema=RootSchema executeClass=Schema executeMethod=_fixDictionariesWithInvalidDateAndTimeKeyValues

Persistent DynaDictionaries with external keys that have invalid Date or Time values must be rebuilt manually. These instances are reported when the script is run.

There is concern globally around the Log4shell security update. The Jade team is actively reviewing its systems and those of our customers to ensure they are protected from this exposure.

Our review to date has not identified any issues with customer systems that are not mitigated by in-place protections.  Note, the JADE product itself is not susceptible to this vulnerability.

Jade will continue to actively monitor and review its systems and those of our customers to ensure they are protected from this exposure. 

If you have any questions, please contact our 24x7 Central Systems team in the normal way.

Beginning in 20.0.02, the RPS data pump will not replay updates to Many to Many SQL tables.  
This does not affect the Load operations of Many to Many tables.

A hotfix has been created to address this issue (20.0.02.021).  

Note: As no incremental Create/Update/Delete operations have been applied to any Many to Many tables while running at 20.0.02, installing the hotfix at any point after this could cause the data pump to error and stop. For example, attempting to delete a M2M table entry that was never created by the data pump. 
 
Before the data pump is restarted and running with the hotfix all Many to Many tables will need to be reloaded. 

The hotfix should only be installed after following the following procedure.  

1. a) Stop RPS database while it is up to date and synchronized with the Primary 
   b) Install hotfix 
   c) Start RPS database, with the data pump NOT running 
   d) Truncate data from of the many to many tables (to avoid PK collisions) 
   c) Perform Extract and Load (full clones) of each of the Many to Many tables 
   e) Start the data pump  

Alternatively, a full rebuild of the RPS/SQL database pair could be performed with the hotfix installed. 

If you have any questions, please contact jadesupport@jadeworld.com 

Changes to file extent management introduced with hotfixes: 16.0.02.046, 18.0.01.092 & 20.0.01.038 result in logical file extents being allocated according to configuration information associated with a database; specifically, the PersistentDb.DefFileGrowthIncrement INI setting or in the extentSize attribute set using dbutil for each database file, rather than a fixed value. 

A consequence of these changes is that the replay of file reorgs on SDS secondary database became sensitive to file extent size configuration. When a file reorg is replayed on a secondary database and the file (for any reason) has different extent size values to those on the primary database, the reorged file on the secondary will diverge in structure from the reorged file on the primary. Structural divergence will cause failures replaying subsequent journaled updates to the reorged file on the secondary database.

The problem could also occur when hotfixes 16.0.02.046, 18.0.01.092 & 20.0.01.038 (or higher) were installed on the primary database but not the secondary (or vice versa).

Install the hotfix, 16.0.02.050 18.0.01.099 or 20.0.01.047 

The issue has been resolved by ensuring file reorgs use an invariant extent size to remove sensitivity to variations in primary versus secondary configuration.  

Notes:
1) It is important to ensure that when you install any of these hotfixes (or higher versions) on a primary database you also install it on secondary database before the secondary is required to replay a reorg executed on the primary.  

To check this has been done, a sdsUpgradeVersionCheck audit record is journalled on the primary prior to the execution of a replayable reorg. When the version check audit record is replayed by a secondary database, tracking will halt if (and only if) the minimum level hotfix is not installed.  

The following messages will be logged.
2021/06/09 17:14:08.262 09618-0214 SDS: Secondary upgrade version mismatch: tracking will now halt
2021/06/09 17:14:08.267 09618-0214 SDS: Upgrade to the same software release level as the primary and restart server

2) There is no check to detect the scenario where this hotfix is installed on the secondary and not the primary.

3) We strongly recommend you take an online backup after the hotfixes have been installed so that you can safely execute a roll forward recovery through a replayable reorg with a single consistent set of code files.

In Jade 2020, under certain situations existing entries in an array with variable membership type (Binary, String, or StringUtf8) are overwritten with null when an entry is added or inserted. This can happen to persistent arrays that are upgraded from 2018 if the array membership is variable type. Whether this error occurs is dependent on the maximum length of the array membership type and the population of the array in 2018. The number and length of the initial values and number and length of values added to the array in 2020 are also relevant.

Install the hotfix 20.0.01.043. Ensure all systems upgraded to Jade 2020 are upgraded to at least hotfix 20.0.01.043.