Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Release Notes

Red Hat Trusted Artifact Signer 1.1

Release notes for Red Hat's Trusted Artifact Signer 1.1.2

Red Hat Trusted Documentation Team

Abstract

Welcome to Red Hat Trusted Artifact Signer's official release notes for version 1.1.2!
The release notes describes new features, enhancements, known issues, bug fixes, and deprecation implemented for the Red Hat Trusted Artifact Signer 1.1.2 software release.
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright's message

Chapter 1. Introduction
Copy link

Red Hat’s Trusted Artifact Signer (RHTAS) service enhances software supply chain security by simplifying cryptographic signing and verifying of software artifacts, such as container images, binaries, and Git commits. Trusted Artifact Signer provides a production ready deployment of the SecureSign community project.

The Trusted Artifact Signer software Release Notes documents new features and enhancements, bug fixes, and known issues for the latest version, 1.1.1. We add the newest items to the top in each chapter, as we build upon the official release notes over the lifecycle of the major, and minor releases.

The Red Hat Trusted Artifact Signer documentation is available here.

Chapter 2. New features and enhancements
Copy link

A list of all major enhancements, and new features introduced in this release of Red Hat Trusted Artifact Signer (RHTAS).

The features and enhancements added by this release are:

Log sharding for Rekor

If left alone, Rekor’s log will grow indefinitely, which can impact overall performance. With this release, we added log sharding for Rekor to help manage scaling, and minimizing any potential performance degradation from having large logs. You can configure sharding by directly modifying the Rekor custom resource (CR). For more information about how to configure log sharding for Rekor’s signer key rotation, see the RHTAS Administration Guide.

Log sharding for CT log

If left alone, Certificate Transparency (CT) log will grow indefinitely, which can impact overall performance. With this release, we added log sharding for CT log to help manage scaling, and minimizing any potential performance degradation from having large logs. You can configure sharding by directly modifying the CT log custom resource (CR). For more information about how to configure log sharding for CT log’s signer key rotation, see the RHTAS Administration Guide.

Deploy Trillian independently

With this release, you can deploy the Trillian service independently of all other RHTAS components. You can now deploy an independent version of Trillian that uses the RHTAS operator.

Deploy Rekor independently from Trillian

In earlier releases of RHTAS, Rekor required the Trillian service, along with the Trillian database, to be running in the same namespace as Rekor. Because of this dependency, deploying Rekor in complex or segmented environments was more challenging. With this release, we made Rekor independent from Trillian, giving users the flexibility to implement Trillian in a way that is more adaptable to complex infrastructure configurations. Because of this new feature, we extended the API, which allows you to specify connection information for the Trillian service. You can specify the Trillian connection information by providing the appropriate values to the spec.trillian.host and spec.trillian.port options in the Securesign resource.

Proxy support for the Trusted Artifact Signer operator

Connections are often established by using proxies in OpenShift environments, and this might be a hard requirement for some organizations. With this release, we added support for configured proxies in OpenShift environments to the RHTAS operator and operands.

Trusted Timestamp Authority support added

By default, the timestamp comes from Rekor’s own internal clock, which is not externally verifiable or immutable. By using signed timestamps from trusted Timestamp Authorities (TSAs) this mitigates the risk of Rekor’s internal clock being tampered with. With this release, you can configure a trusted TSA instead of using Rekor’s internal clock.

Support for custom Rekor UI route for Ingress sharding

With this release, you can set a custom route for the Rekor user interface (UI) to work with OpenShift’s Ingress Controller sharding feature.

You can configure this by modifying the externalAccess section of ingress and route resources, adding the type: dev label under the routeSelectorlabels section. For example: 

...
    externalAccess:
      enabled: true
      routeSelectorLabels:
        type: dev
...
Copy to Clipboard Toggle word wrap

This allows the Ingress Controller to identify these resources for specific preset routes, in this case the dev route.

The operator supports custom CA bundles with certificate injection

With this release, the RHTAS operator now supports custom Certificate Authority (CA) bundles by using certificate injection. To ensure secure communications with OpenShift Proxy or other services needing to trust a specific CA, the RHTAS operator automatically injects trusted CA bundles into its managed services. These managed services are: Trillian, Fulcio, Rekor, Certificate Transparency (CT) log, and Timestamp Authority (TSA).

You can trust additional CA bundles by referencing the config map containing the custom CA bundle in one of two ways:

  • In the relevant custom resource (CR) file, under the metadata.annotations section, add rhtas.redhat.com/trusted-ca.
  • Configure a custom CA bundle directly in the CR file by adding the trustedCA field in the spec.

Configure a CT log prefix for Fulcio

With this release, we added the ability to configure a Certificate Transparency (CT) log prefix for Fulcio. In earlier releases, we hard-coded the prefix to trusted-artifact-signer. Making the prefix configurable, gives you more flexibility, and allows you to target specific CT logs within the CT service. The Fulcio custom resource definition (CRD) has a new spec.ctlog.prefix field, where you can set the prefix.

Enterprise Contract can initialize the TUF root

With this release, you can now use the ec sigstore initialize --root ${TUF_URL} command to initialize Enterprise Contract with The Update Framework (TUF) root deployed by RHTAS. Doing this initialization stores the trusted metadata locally in $HOME/.sigstore/root.

Support for excluding rules for specific images in an Enterprise Contract policy

With this release, you can add an exclude directive in the volatileConfig section of an Enterprise Contract (EC) policy for a specific image digest. You can specify an image digest by using the imageRef key, which limits the policy exception to one specific image.

Support for organizational level OCI registry authentication

With this release, Enterprise Contract (EC) supports Open Container Initiative (OCI) registry credentials specified by using a subpath of the full repository path. If many matching credentials are available, then it tries them in order of specificity. For more information, see the authentication against container image registries specification.

Improved the auditing of Enterprise Contract policy sources

With this release, we log an entry for a Git SHA, or a bundle image digest for each policy source. This allows for better auditing of Enterprise Contract (EC) results, showing you the exact version of the policies and policy data used by EC, allowing for reproducibility.

Displaying plain text as the default for Enterprise Contract reports

With this release, we changed the default output format for the Enterprise Contract (EC) report to plain text. The plain text format makes reading the EC results report much easier.

Chapter 3. Bug fixes
Copy link

In this release of Red Hat Trusted Artifact Signer (RHTAS), we fixed the following bugs. In addition to these fixes, we list the descriptions of previously known issues found in earlier versions that we fixed.

Added missing options to configure hostname

With this release, you can now configure the hostname for the cli-server and the rekor-search-ui. You can configure the hostname by specifying the --cli-server-hostname=HOSTNAME on the RHTAS operator controller. You can also configure the hostname by using the API, for example: 

...
  rekor:
    rekorSearchUI:
      host: HOSTNAME
...
Copy to Clipboard Toggle word wrap

Replace HOSTNAME with your hostname.

Segment backup job fails on OpenShift clusters that use self-signed certificates

The segment backup job was failing when verifying a self-signed certificate causing Secure Socket Layer (SSL) certificate verification errors. Because this verification failed, the job could not pull metrics from the cluster monitoring system by using OpenShift’s internal API. We fixed this bug by injecting OpenShift’s Certificate Authority (CA) trusted bundle into the RHTAS containers. By doing this, the segment backup job can verify the self-signed certificate, and can successfully pull the necessary metrics.

Version number reported incorrectly on OpenShift 4.13

Before this update, the installation of the RHTAS operator on OpenShift Container Platform 4.13 incorrectly shows version 0.0.2, when version 1.0 is actually installed. With this release, the RHTAS operator version number is correctly displayed on OpenShift Container Platform 4.13.

Removed pull-secret references

In early releases of RHTAS, you were asked to give a pull secret to install RHTAS. Since the General Availability (GA) release of RHTAS, you no longer need a pull secret to deploy RHTAS on Red Hat OpenShift. With this release, we removed all references to pull-secret from the RHTAS code base.

Changes to the treeID field are not applied to the Rekor deployment

When making a change to the treeID field in the Rekor configuration this change was not updated in the Rekor deployment. This bug could cause wrong log entries, and cause other potential issues with Rekor. We fixed the logic in the Rekor manager to prevent inconsistencies, and as a result improving the reliability of the Rekor service. With this release, updating the treeID field correctly updates the Rekor deployment as expected, and shows the correct status.treeID value.

Changes to the treeID field are not applied to the CT log deployment

When making a change to the treeID field in the Certificate Transparency (CT) log configuration this change was not updated in the CT log deployment. This bug could cause inconsistencies, and other potential issues with CT log. We fixed the logic in the CT log manager to prevent inconsistencies, and as a result improving the reliability of the CT log service. With this release, updating the treeID field correctly updates the CT log deployment as expected, and shows the correct status.treeID value.

Chapter 4. Known issues
Copy link

Resolved known issues for this release of Red Hat Trusted Artifact Signer (RHTAS):

A list of known issues found in this release RHTAS:

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. To workaound this issue, run the provided script after the Securesign resource is restored. This script recreates the ownerReferences with the new Securesign UUID.

Specifying a PVC name for the TUF repository fails the initialization process

When specifying a persistent volume claim (PVC) name in The Update Framework (TUF) resource causes the RHTAS operator to fail the initialization of the TUF repository. For example: 

spec:
...
  tuf:
    ...
      pvc:
        name: tuf-pvc-example-name
...
Copy to Clipboard Toggle word wrap

To workaround this issue, do not specify a PVC name in the TUF resource. This allows the RHTAS operator to automatically create the PVC, names it tuf, and properly initializes the TUF repository.

Rekor Search UI does not show records after upgrade

After upgrading the RHTAS operator to the latest version (1.0.1), the existing Rekor data is not found when searching by email address. The backfill-redis CronJob, which ensures that Rekor Search UI can query the transparency log only runs once per day, at midnight. To workaround this issue, you can trigger the backfill-redis job manually, instead of waiting until midnight.

To trigger the backfill-redis job from the command-line interface, run the following command: 

$ oc create job --from=cronjob/backfill-redis backfill-redis -n trusted-artifact-signer
Copy to Clipboard Toggle word wrap

Doing this adds the missing data back to the Rekor Search UI.

The Trusted Artifact Signer operator does not apply configuration changes

We found a potential issue with the RHTAS operator logic that can cause an unexpected state when redeploying. This inconsistent state can happen if removing configurations from RHTAS resources and the operator tries to redeploy those resources. To workaround this potential issue, you can delete the specific resource, and then re-create that resource by using the previous instance’s configuration, such as keys, and persistent volumes. The RHTAS resources are: Securesign, Fulcio, The Update Framework (TUF), Rekor, Certificate Transparency (CT) log, or Trillian.

For example, to delete the Securesign resource: 

$ oc delete Securesign securesign-sample
Copy to Clipboard Toggle word wrap

For example, to re-create the Securesign resource from a configuration file: 

$ oc create -f ./securesign-sample.yaml
Copy to Clipboard Toggle word wrap

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. Currently, you have to manually delete the securesign-sample-trillian-db-tls resource, and manually update the component status links. The RHTAS operator will automatically recreate an updated securesign-sample-trillian-db-tls resource, after it has been removed.

After the backup procedure starts, and the secrets restored, delete the securesign-sample-trillian-db-tls resource:

Example

$ oc delete secret securesign-sample-trillian-db-tls
Copy to Clipboard Toggle word wrap

Once all the pods start, then update the status files for Securesign, and TimestampAuthority:

Example

$ oc edit --subresource=status Securesign securesign-sample
$ oc edit --subresource=status TimestampAuthority securesign-sample
Copy to Clipboard Toggle word wrap

Trusted Artifact Signer requires cosign 2.2 or later

Because of recent changes to how we generate The Update Framework (TUF) repository, and making use of different checksum algorithms, we require the use of cosign version 2.2 or later. With this release of RHTAS, you can download cosign version 2.4 for use with Trusted Artifact Signer.

Legal Notice
Copy link

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
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