红帽全球峰会此内容没有您所选择的语言版本。
Chapter 4. Bug fixes
In this release of Red Hat Trusted Artifact Signer (RHTAS), we fixed the following bugs. In addition to these fixes, we also list the descriptions of previously known issues found in earlier versions that we fixed.
- The Trusted Artifact Signer Operator does not apply configuration changes
- In this update, the Operator logic, which previously ensured deployment was in the expected state, had a gap, leading to issues with deployment modification. Consequently, if configuration parts were actively removed, the deployment might not match the expected state. With this release, the function responsible for maintaining the deployment’s expected state has been comprehensively redesigned and replaced, eliminating this gap. As a result, the new function correctly handles any resource updates, ensuring the deployment is always in the required state.
- Specifying a PVC name for the TUF repository fails the initialization process
- In this release, we updated the RHTAS Operator to correctly interpret the provision of a name for a Persistent Volume Claim (PVC) for The Update Framework (TUF) resource. Before this update, the TUF repository was not initialized due to this misinterpretation. With this update, during installation, the Operator will use the provided name when creating the TUF repository, ensuring that TUF repositories with a specified name are properly initialized.
- Creation of ingress objects occurs even if
externalAccess.enabledis set tofalse -
In this update, the Operator’s logic for creating ingress objects now actively evaluates the
externalAccesssetting in the Securesign custom resource. Before this update, this evaluation was incorrect, leading to the creation of ingress objects for Fulcio, Rekor Search UI, and the Timestamp Authority even whenexternalAccess.enabledwas set tofalse. With this release, the Operator ensures thatexternalAccess.enabledistruebefore an ingress object is created, preventing the creation of ingress objects when external access is intentionally disabled for a component. This change correctly reflects the configuration specified in the Securesign custom resource.
- Displaying the correct digest algorithm within the trust root
Before this update, The Update Framework (TUF) did not validate trust roots thoroughly. This lead to displaying the wrong signature algorithm for keys as SHA384 instead of SHA256, resulting in incorrect key details in the signed target trust root. This issue has been addressed in this release by adding extra key validation to TUF. As a result, the signed target trust root will now show the correct key details on fresh deployments. Existing deployments will require rotation of the Rekor key for proper functioning.
For information about how to rotate Rekor’s signer key for RHTAS running on Red Hat OpenShift or on Red Hat Enterprise Linux, see the RHTAS Administration Guide.
- Downgraded the creation of the Rekor signer key from SHA384 to SHA256
- Before this update, the RHTAS Operator and Ansible collection created signer keys that were not compatible with Rekor’s 256-bit requirement, leading to potential validation issues. This was due to the generation of 384-bit SHA384 keys instead of the expected 256-bit SHA256 keys. In this release, we adjusted the signer keys to be consistent with Rekor’s specifications, resulting in improved compatibility and stability for end users.
- Unstable service under high load because of unmanaged database connections
- In this update, the default database connection pool for client components, such as, the Trillian log server previously had no limits, leading to excessive TCP connections to the database under heavy load. This resulted in ephemeral port exhaustion on client pods, causing component crashes with "cannot assign requested address" errors and subsequent failures, including "500 Internal Server Error" responses from Fulcio. With this release, limits have been set for the Rekor and Trillian database clients, controlling the maximum number of open and idle connections, and connection lifetimes. This improvement ensures the system remains stable under high load conditions, preventing port exhaustion and eliminating "cannot assign requested address" errors and subsequent failures.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}