

.. _section-whats-fixed-750:

What's Fixed in 7.5.0
=====================
This section describes bugs fixed in |RTI_SP_PRODUCT| 7.5.0. 
These are fixes made since :ref:`section-whats-fixed-740`.

*Connext* 7.5.0 is an early access release (EAR).
See `Connext Versions and Lifecycle <https://community.rti.com/connext-releases>`_ 
for more information on RTI's software release model.

For what's fixed in other products in the |CONNEXT| suite, see
those products' release notes on the `RTI Community Portal <https://community.rti.com/documentation>`__ 
or in your installation.

.. include:: ../../../../../connext_doc.1.0/srcDoc/release_notes/whats_fixed/severity_levels.txt  

.. Release Notes from this point.


Discovery and Authentication
----------------------------

:critical:`[Critical]` Unable to communicate with DomainParticipants that propagate 1.0 class_id and use P384 or experimental algorithms
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Starting in release 7.4.0, *DomainParticipants* propagate by default the
``DDS:Auth:PKI-DH:1.2`` **class_id**. This change was made to conform
with the DDS Security 1.2 Specification. However, in some scenarios, the
update was not backwards compatible with *DomainParticipants* still
propagating the ``DDS:Auth:PKI-DH:1.0`` **class_id**. 
Specifically, backward interoperability was broken for the P384 or experimental
digital signature (``ECDSA+P384+SHA384``, ``EDDSA+ED25519+SHA512``,
``EDDSA+ED448+SHAKE256``) and key establishment algorithms
(``ECDHE-CEUM+P384``, ``ECDHE-CEUM+X25519``, ``ECDHE-CEUM+X448``).
Discovery would not complete and the
``unexpected key establishment algorithm`` or 
``unexpected digital signature and digest type combination`` messages
were logged.

[RTI Issue ID SEC-2649]


Dynamic Participant Renewal, Revocation, and Expiration
-------------------------------------------------------

:critical:`[Critical]` Loss of data when banishing more than 16,777,208 times
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Consider the following scenario:

- The *DomainParticipantQos* property
  ``dds.participant.trust_plugins.key_revision_max_history_depth`` is
  set to a value other than 0.

- The Governance Rule ``<data_protection_kind>`` is set to a value other
  than ``NONE`` for a given topic.

- A given *DomainParticipant* banishes participants (e.g., by calling
  the API function ``banish_ignored_participants``) more than 16,777,208
  times but less than 16,777,215 times.

- A *DataWriter* of the given topic within this *DomainParticipant* has
  historical samples in its queue that were written using much older
  revisions.

- A *DataReader* of the given topic joins late and tries to receive
  these historical samples.

When this scenario occurred in previous releases, the *DataReader* would
fail to get these historical samples. This log message accompanied this
failure:

::

   PRESReaderQueueSecurity_decode:FAILED TO DECODE | Incoming serialized data.

[RTI Issue ID SEC-2613]


Crashes
-------

:critical:`[Critical]` Log messages possibly corrupted or lost due to memory reordering on weak memory architectures
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On weak memory architectures (such as Arm), memory reordering negatively
impacted the logging queue used for distributing security events and
logging over DDS.

If the queue became full (which can happen if your application generates
many log messages, such as when debug verbosity is set), some log
messages may have been lost or corrupted.

If the queue was empty and a new message was produced, it could have
caused a crash or an incomplete message being published.

These issues have been resolved by adding memory barriers to the logging
queue implementation.

[RTI Issue ID SEC-2587]


:critical:`[Critical]` NULL dereference when simultaneously changing certificate or CRL file while deleting DomainParticipant
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Suppose you had set ``files_poll_interval`` to a value other than 0. If
you changed the contents of an identity certificate file or a CRL file
while deleting the *DomainParticipant*, a race condition would have
occurred because those two operations were not thread-safe with respect
to each other. This race condition led to a NULL dereference in release
libraries and a precondition failure in debug libraries in the internal
function ``DDS_DomainParticipantGlobals_get_worker_per_threadI``.

[RTI Issue ID SEC-2618]


:critical:`[Critical]` Segmentation fault risk with concurrent updates of identity certificates
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There was the risk of a segmentation fault with concurrent updates of identity
certificates. It was possible to cause a *DomainParticipant* crash when an
identity certificate was updated via different avenues at the same time: that
is, via identity certificate file change and via the ``set_qos`` API.

[RTI Issue ID SEC-2676]



Memory Leaks/Growth
-------------------

:critical:`[Critical]` Unbounded memory leak if identity certificate file was polled and emptied repeatedly
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Consider the following scenario:

- The ``dds.sec.auth.identity_certificate`` property is set to a file on
  the file system.

- The ``files_poll_interval`` property is unset or set to a value other
  than 0.

- After you create the *DomainParticipant*, the certificate file on the
  file system is emptied.

In this scenario, the *Builtin Security Plugins* will correctly fail to
read the updated certificate file and print this error:

::

   ERROR RTI_Security_URIHelper_getStringBuiltin:!failed to read from file

When this scenario occurred in previous releases, the problem was that a
memory leak of one byte accompanied this error. Repeatedly “touching”
(i.e., updating the “last modified” timestamp of) this empty file
resulted in repeated one-byte memory leaks.

The unbounded memory leak only affected versions 7.2.0, 7.3.0 to
7.3.0.2, and 7.4.0.

[RTI Issue ID SEC-2525]
