Jade Platform Critical Hotfixes: Key Updates Repository

The Problem

Affected versions are JADE 2020 onwards (20.0.01, 20.0.02, 22.0.01 & 22.0.02)

Entries in an array with membership type Any, Binary, String, or StringUtf8 are set to null by the Array::atPut() method, if the value of the index parameter causes the size of the array to increase by more than 1 entry. The exact value that triggers the problem is dependent on the maximum size of the membership and the number of entries in the array when the atPut() method is called. The problem is unlikely to occur if the array contains fewer than 100 entries. The array can have any lifetime: persistent, transient, or shared transient.

Also note that the Array index operator array[index] := value; uses atPut() .

The Solution

Install hotfix 20.0.02.062 or 22.0.02.012

A script has been prepared that can be run in a workspace. This script will scan all persistent arrays of Any, Binary, String, and StringUtf8, and report any null entries. The arrays reported must be checked manually to determine if there is a problem with any null values.

Please contact support@jadeplatform.tech to obtain a copy of the script.

OpenSSL Upgrade to latest version (1.0.2 to 3.0.8)

Issue is addressed by hotfixes in 22.0.01.022, 20.0.02.054, 18.0.01.126, & 16.0.02.063

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 64-bit and libssl-3.dll, libcrypto-3.dll for 32-bit 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.

For example, 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 support@jadeplatform.tech

Dictionaries with invalid Date and Time key values are not sorted correctly in 2020 SP1

Issue is addressed by 20.0.02.024 hotfix

The Problem

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 need 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.

The Solution

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.

Who needs this?

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.

Important message regarding the Log4Shell Security Update

The Problem

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 that the Jade product itself is not susceptible to this vulnerability.

The Solution

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.

RPS Data Pump Issue in 2020 SP1 - Many-to-Many tables not updated by data pump

Issue is addressed by 20.0.02.021 hotfix

The Problem

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.

The Solution

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

Note: As no incremental Create/Update/Delete operations has 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 raise an error and stop. For example, attempting to delete a Many-to-Many 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 the following procedure.

Stop RPS database while it is up to date and synchronised with the Primary
Install hotfix
Start RPS database, with the data pump NOT running
Truncate data from of the Many-to-Many tables (to avoid PK collisions)
Perform Extract and Load (full clones) of each of the Many-to-Many tables
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 support@jadeplatform.tech

SDS Reorg Replay Issue - Reorg replay became sensitive to variations in database configuration

Issue is addressed by 16.0.02.050, 18.0.01.099 & 20.0.01.047 hotfixes

The Problem

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

A consequence of these changes is that the replay of file reorgs on SDS secondary databases 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, and 20.0.01.038 (or higher) were installed on the primary database but not the secondary (or vice versa).

The Solution

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, an 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.

Critical Database File Corruption Issue

Issue is addressed by 16.0.02.048, 18.0.01.096, and 20.0.01.040 hotfixes

Note: These hotfixes supersede: 16.0.02.046, 18.0.01.092, and 20.0.01.038.

The Problem

1) A background flush of blocks recently appended to the end of a file could overlap with physical file extension during a database checkpoint. When the overlap occurred, there was a timing window that under some conditions could result in file truncation and data loss.
While it is considered a very rare scenario that the issue occur, we advise all users to install the relevant hotfix as soon as possible.

2) Prior to a recent hotfix, the extentSize attribute was only used to control physical file extension. Now it is also used to control the size of logical extents. Jade releases since 5.2.8 have not allowed the control file value to be set smaller than 64K, but legacy values have been carried through release upgrades without being checked or corrected.
To handle the legacy values that may be present in user databases that began their life prior to 5.2.8, the database engine now detects and automatically corrects invalid values. When invalid values below the current 64K minimum are detected, a warning is logged in the jommsg log and the control file value is set to zero. A zero value is interpreted to mean use the jade.ini file configured value for DefFileGrowthIncrement (default = 128K, minimum = 64K).

The Solution

Install the hotfix: 16.0.02.048, 18.0.01.096, and 20.0.01.040.

Critical Database File Corruption Issue

Issue is addressed by 16.0.02.046, 18.0.01.092, and 20.0.01.038 hotfixes

The Problem

A background flush of blocks recently appended to the end of a file could overlap with the physical file extension during a database checkpoint.
When the overlap occurred, there was a timing window that under some conditions could result in file truncation and data loss.

While it is considered a rare scenario that the issue occurs, we advise all users to install the relevant hotfix as soon as possible.

The Solution

Install the hotfix, 16.0.02.046, 18.0.01.092, or 20.0.01.038.

.NET Import Issue in Jade 2018 and 2020

Issue is addressed by 16.0.02.048, 18.0.01.085, and 20.0.01.020 hotfixes

Note: The initial hotfixes 18.0.01.084 and 20.0.01.018 were withdrawn and replaced by these two.

The Problem

With the release of Jade 18.0.01, the .NET external component library wizard was updated to support two new type conversions.

DateTimeOffset .NET type now maps to TimeStampOffset JADE type
Byte[] .NET type now maps to Binary JADE type

Both of these types previously mapped to JadeDotNetType in earlier releases.
Hotfix 18.0.01.074 was later released, as it was found the new Binary type conversions were not working.

It has now come to our attention that as of hotfix 18.0.01.074 (including 20.0.01), any assemblies that were imported with the previous mapping (Byte[] to JadeDotNetType) can cause exceptions if attempting to access properties or methods with these types.

The Solution

To ensure backwards compatibility while also supporting these new mappings, we are releasing a new hotfix in Jade 18.0.01.085 and 20.0.01.020 that supports both the old and new type mappings. Any assemblies imported prior to Jade 18.0.01 will continue to function as expected after applying this hotfix.

However, as this was not introduced with the initial release of 18.0.01, it may require a fix-up script to be run to correct the generated JadeDotNetType methods and compatibility flags.

Who needs this?

Any Jade 18.0.01 or 20.0.01 systems that have had .NET assemblies imported/re-imported in either release AND have imported either of the following:

Imported .NET classes with properties, fields, method/event parameters/return values of the type DateTimeOffset
Imported .NET classes with properties, fields, method/event parameters/return values of the type Byte[]

The fix-up method `RootSchema::Schema::_fixDotNetImportMethodsAndSetFlags` will need to be executed once after applying the hotfix if the system meets the above criteria. This script will modify and recompile the necessary generated methods for affected assemblies, as well as set some compatibility flags on the generated assembly meta data.

We have also provided another method `RootSchema::Schema::_fixDotNetImportCompatibilityFlags` that will just perform setting the compatibility flags. This method should be used if the method changes are deployed to the system.

Alternatively, any imported .NET assemblies that meet the above criteria can be re-imported after applying the hotfix. This will cause the methods to be generated correctly and compatibility flags to be set.

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=_fixDotNetImportMethodsAndSetFlags>

Critical Hotfixes

PAR 69585 - 15 Aug 2023

Arrays with variable size entries can become null with use of atPut() method

The Problem

The Solution

Previous Critical Hotfixes

OpenSSL Upgrade to latest version (1.0.2 to 3.0.8)

Dictionaries with invalid Date and Time key values are not sorted correctly in 2020 SP1

The Problem

The Solution

Who needs this?

Important message regarding the Log4Shell Security Update

The Problem

The Solution

RPS Data Pump Issue in 2020 SP1 - Many-to-Many tables not updated by data pump

The Problem

The Solution

SDS Reorg Replay Issue - Reorg replay became sensitive to variations in database configuration

The Problem

The Solution

Critical Database File Corruption Issue

The Problem

The Solution

Critical Database File Corruption Issue

The Problem

The Solution

.NET Import Issue in Jade 2018 and 2020

The Problem

The Solution

Who needs this?

Need Help?