uses: actions/checkout@755da8c3cf115ac066823e79a1e1788f8940201b # v3.2.0
      - name: Trusted-Partners-PR
        uses: actions/github-script@d556feaca394842dc55e4734bf3bb9f685482fa0 # v6.3.3
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const script = require('./.github/workflows/trusted_partners.js');
            const username = context.payload.pull_request.user.login;

      val toVerify = result[result.size - 1] as X509Certificate

      // If this cert has been signed by a trusted cert, use that. Add the trusted certificate to
      // the end of the chain unless it's already present. (That would happen if the first
      // certificate in the chain is itself a self-signed and trusted CA certificate.)
      val trustedCert = trustRootIndex.findByIssuerAndSignature(toVerify)
      if (trustedCert != null) {

        selfSigned.certificate,
        trusted.certificate,
      )
    assertThat(cleaner.clean(list(certB, certA), "hostname")).isEqualTo(
      list(certB, certA, trusted, selfSigned),
    )
    assertThat(cleaner.clean(list(certB, certA, trusted), "hostname")).isEqualTo(
      list(certB, certA, trusted, selfSigned),
    )
    assertThat(cleaner.clean(list(certB, certA, trusted, selfSigned), "hostname"))
      .isEqualTo(

    /**
     * Configure the certificate chain to use when being authenticated. The first certificate is
     * the held certificate, further certificates are included in the handshake so the peer can
     * build a trusted path to a trusted root certificate.
     *
     * The chain should include all intermediate certificates but does not need the root certificate
     * that we expect to be known by the remote peer. The peer already has that certificate so

-----------------------

The above example uses a self-signed certificate. This is convenient for testing but not
representative of real-world HTTPS deployment. To get closer to that we can use `HeldCertificate`
to generate a trusted root certificate, an intermediate certificate, and a server certificate.
We use `certificateAuthority(int)` to create certificates that can sign other certificates. The

 * certificate is signed by the certificate that follows, and the last certificate is a trusted CA
 * certificate.
 *
 * Use of the chain cleaner is necessary to omit unexpected certificates that aren't relevant to
 * the TLS handshake and to extract the trusted CA certificate for the benefit of certificate
 * pinning.
 */
abstract class CertificateChainCleaner {

  env:
    PILOT_ENABLE_AMBIENT: "true"
    # Allow sidecars/ingress to send/receive HBONE. This is required for interop.
    PILOT_ENABLE_SENDING_HBONE: "true"
    PILOT_ENABLE_SIDECAR_LISTENING_HBONE: "true"
    CA_TRUSTED_NODE_ACCOUNTS: "istio-system/ztunnel,kube-system/ztunnel"
variant: distroless
seLinuxOptions:

meshConfig:
  defaultConfig:
    proxyMetadata:
      ISTIO_META_ENABLE_HBONE: "true"
global:
  variant: distroless
pilot:
  env:
    PILOT_ENABLE_AMBIENT: "true"
    CA_TRUSTED_NODE_ACCOUNTS: "istio-system/ztunnel,kube-system/ztunnel"
cni:
  ambient:
    enabled: true

# Ztunnel doesn't use a namespace, so everything here is mostly for ztunnel

meshConfig:
  defaultConfig:
    proxyMetadata:
      ISTIO_META_ENABLE_HBONE: "true"
global:
  variant: distroless
pilot:
  env:
    PILOT_ENABLE_AMBIENT: "true"
    CA_TRUSTED_NODE_ACCOUNTS: "istio-system/ztunnel,kube-system/ztunnel"
cni:
  ambient:
    enabled: true

# Ztunnel doesn't use a namespace, so everything here is mostly for ztunnel

meshConfig:
  defaultConfig:
    proxyMetadata:
      ISTIO_META_ENABLE_HBONE: "true"
global:
  variant: distroless
pilot:
  env:
    PILOT_ENABLE_AMBIENT: "true"
    CA_TRUSTED_NODE_ACCOUNTS: "istio-system/ztunnel,kube-system/ztunnel"
cni:
  ambient:
    enabled: true

# Ztunnel doesn't use a namespace, so everything here is mostly for ztunnel