---
title: Inspecting Releases
framework: Private Cloud Compute Security Guide
role: article
role_heading: Article
path: private-cloud-compute/inspectingreleases
---

# Inspecting Releases

Inspect releases in the transparency log for either node platform.

## Exploring available releases

Exploring available releases You can inspect published releases of the Private Cloud Compute component directly from the live transparency log using the pccvre release command: % pccvre release list Found 10 releases:

19930: TIE (downloadable) 	b4e91d75d4cb2df8b4c2b06bdd1cbe4611fc2d8823cacfe53d93b5676481e192    19929:  (downloadable) 	ea443d36a2cd962570c1201ff20cc1e0265172af0cc99a06994ab306daa49ee6    19162: TIE Proxy (downloadable) 	502b0514e353194b9e16c2cb50920c3e3f7bd2383162e1f2cc572a9fe9aa657f ... By default, the 10 most recent release entries are displayed, each as a release index followed by the application name as published to the transparency log, and a (SHA-256) digest of the release structure the entry records. The name of an application that runs on a Google Cloud node ends in a suffix identifying the platform, so the listing tells you which kind of node a release targets. As older devices don’t support Transitive Trust, any releases for such clients don’t have an application name listed. Apple may also withhold a release’s leaf metadata, including its application name and CDN download location, for up to 90 days, for example, to avoid revealing an unannounced application. See Binary transparency. Releases in this state are listed without an application name until the metadata is published. If multiple releases have the same digest, only the newest one is displayed unless the --all option is used. There are additional types of entries in the transparency log that are not listed by this command, and account for gaps in the index numbers, for example, key bundles and “liveness” checks used by operations. A Google Cloud node contributes Release structures, and both appear in this listing: a software release covering the code the node runs, and a firmware release covering the node’s Titan security chip, its baseboard management controller (BMC), its BIOS, and its GPU firmware. An Apple silicon node contributes one kind of release. Use pccvre release dump to view additional details for a release. What it displays depends on which structure the entry holds: Adding --detail appends the release’s published metadata, which names each downloadable asset and its URL; adding --json emits the whole entry, including the raw encoded release, for a tool to consume.    19930: TIE (downloadable) 	b4e91d75d4cb2df8b4c2b06bdd1cbe4611fc2d8823cacfe53d93b5676481e192

Expires: 2025-07-11T00:33:45 Created: 2025-06-05T14:55:44 Application: TIE Tickets       OS: ef571c0f38c4493008d43de4b298adcfb9db849e9d317f1bfd7c26d2dc289e70     Cryptexes     Code: eb0312520bb2e189f6dd97a340018c01be0a7d8e9b2229c314e0099149c41cb6     Data: 89841dd34a6857bb450b26b3f86cefd3630f44a27222032c79ea1c0b8ea3b948     Data: 11e677bb222f35da0fb26dbd5994614d9d1a0e2401f4824099f817b255b23c08     Data: 13dcddb266ceda432eeb09f14e5c19b16e0d8f90f640dcb83fb6674e3b101080     Data: 2eb87b63c64ece5a96c5a27b7141ed1739c36940f381a3da98988a97088d0862 The --count and --start/--end arguments can be used to select ranges (by index number) and the number of past releases. Downloading available releases You can download a release either by index number or its associated digest using the following command: % pccvre release download [--overwrite] <index | sha256> What a download yields depends on the platform the release targets: Auditing the transparency log You can audit the correctness of the PCC transparency log with the transparency-log subcommand: % pccvre transparency-log audit --continuous Top Level Tree: (466098/466098) 	Valid root digest: a77c032ca697ceb467a78a2a71a784f44dc84a86c325a70b465c33323ff4fc41 ✅ Per Application Tree: (30805/30805) 	Valid root digest: 3cf1cdaf4a1414cd7246b66372d5aa413b7d6ffe987194abb06b14809710b452 ✅ Application Tree: (37845/37845) 	Valid root digest: ba94e99d4b6b64d001c6bc4f68f90ebf1026261797ec5a394111f6cc5c15d4ec ✅ waiting 30s until next update

All downloaded leaves are stored as JSON files under ~/Library/Application Support/com.apple.security-research.pccvre/transparency-log/<environment>: % ls ~/Library/Application\ Support/com.apple.security-research.pccvre/transparency-log/production applicationTree.json perApplicationTree.json topLevelTree.json Subsequent invocations of the transparency-log subcommand will resume verification from the previously downloaded leaves. Verifying an attestation’s inclusion proof Attestations contain Merkle inclusion proofs, each in the form of a Log server protocol. An Apple silicon node carries two: one over the Release data structure structure it composes, and one over its DCIK certificate. A Google Cloud node carries three, over its software release, its firmware release, and its device identity certificate. The proof format and the verification procedure are the same in every case. A LogEntry contains several key fields of data that you can use to verify the inclusion proof against a locally constructed view of the transparency log: SignedLogHead, which contains both the revision number and leaf count of the transparency log used to generate the inclusion proof. hashesOfPeersInPathToRoot, which contains an array of peer hashes needed to reconstruct the Merkle root hash. nodePosition, which indicates the index of the leaf node for which the inclusion proof is generated. With all of these items, you can use the information received from the SignedLogHead to slice a local copy of the transparency log from 0..<logSize. This constructs a view of the transparency log just as it was when the server created the inclusion proof. The Merkle root hash of this sliced view of the log will match the root hash computed from hashesOfPeersInPathToRoot and nodePosition. For more details on how Merkle inclusion proofs work, see Section 2.1.3 of Certificate Transparency. Assuming you already have a verified and up-to-date local copy of the transparency log from the pccvre transparency-log audit command, you can use the pccvre transparency-log verify-inclusion command to verify a specific attestation from an Appendix: Apple Intelligence Report: % pccvre transparency-log verify-inclusion \     --request-index <request-index> \     --attestation-index <attestation-index> \     <path to Apple_Intelligence_Report.json> Since an Apple Intelligence Report contains many requests, each containing many attestations, you must provide both the request index and the attestation index for a given request. For example, to verify the first attestation of the first request: % pccvre transparency-log verify-inclusion \     --request-index=0 \     --attestation-index=0 \     ~/Downloads/Apple_Intelligence_Report.json

Successfully verified inclusion proof ✅ (revision: 7211, index: 7798, logSize: 7901, rootDigest: a8f06134677b3034ee2cb4359546b6032a427a031de5d4df613e8666275aa104) You can use pccvre release dump -R <index> to view information about the release.