Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

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.

Operator does not update the component status after doing a restore to a different OpenShift cluster
When restoring the RHTAS signer data from a backup to a new OpenShift cluster, the component status links do not update as expected. With this release we fixed this issue with the component status.
The ownerReferences are lost when restoring Trusted Artifact Signer to a different OpenShift cluster
When restoring the RHTAS data to a new Red Hat OpenShift cluster, the ownerReferences for components are lost. This happens because the Securesign UUID changes when restoring on a new cluster, and the ownerReferences for each component gets deleted since they are no longer valid. With this release we fixed this issue with the ownerReferences for components.
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.enabled is set to false
In this update, the Operator’s logic for creating ingress objects now actively evaluates the externalAccess setting 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 when externalAccess.enabled was set to false. With this release, the Operator ensures that externalAccess.enabled is true before 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.
After a system reboot the cli-server and rekor-search components are unresponsive
We fixed the image pull policy for the RHTAS components, cli-server and rekor-search, which previously operated with an Always pull policy, unlike other RHTAS components. Because of this, local authentication for registry.redhat.io would be lost after rebooting Red Hat Enterprise Linux, causing both services to repeatedly try pulling images that were already available locally. Consequently, both services failed to start due to image pull errors, making cli-server unresponsive and preventing dependent functionality from working after a reboot. With this release, the image pull policy for these services has been switched to IfNotPresent, allowing them to use the already-cached local images. As a result, both components now start successfully after a reboot, without requiring re-authentication to the external registry.
Cosign initialization fails because of incorrect file permissions
With this release, we fixed the permissions of the root.json file within The Update Framework (TUF) metadata volume to match the TUF defaults of 644. This adjustment allows the web server to read the file, resolving issues that previously caused requests to root.json to return 403 Forbidden message, thereby blocking TUF clients and tools from bootstrapping. The process responsible for writing and syncing the root.json file has also been updated to ensure the correct permissions. As a result, TUF clients can now initialize the trust chain without errors.
Deployed the rekor-server to the default namespace
Upgrading to RHTAS 1.3, the rekor-server deploys with a container image without a non-root UID and GID, causing the Pod Security Admission to block pod creation, and preventing the service from becoming available. With this release, we updated the Dockerfile to explicitly set a non-root UID and GID. As a result, the rekor-server pod can now be successfully created in the default namespace for RHTAS 1.3.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat