Access the UnoLock Client Source Transparency Bundle

Every static deploy to safe.unolock.com publishes a transparency bundle that links the exact CodeCommit commit, build inputs, and signed production assets together. This page distills that workflow so researchers can quickly pull the client source snapshot, confirm it matches production, and analyze the codebase offline.

All steps can be performed on an unprivileged machine with only curl, tar, and Node.js. No AWS credentials, secret tokens, or UnoLock accounts are required.

What Each Release Publishes

Every release folder under https://safe.unolock.com/transparency/<release>/ contains the following artifacts:

  • Source snapshot (source.tar.gz) – a git archive of the deployed commit. It includes the Angular client, eyesonly/, safe-app/, and all lockfiles. Build outputs, secrets, desktop-only projects (for example src-tauri/), and non-production environment files (e.g., environment.dev.ts) are stripped to keep the bundle public-safe.
  • Build metadata (build-info.json) – shows the commit id, build timestamp, CodeBuild commands, and the exact Node/NPM/Angular CLI versions.
  • Transparency index (index.json and ../latest.json) – lists the release identifier, commit hash, and canonical paths for the source archive, build-info, ngsw.json, manifestSignature, and codeSignPublicKey.jwk.
  • Service worker bundle – published independently under transparency/service-worker/<release>/ with its own source.tar.gz, build-info.json, and SHA-256 hash of /signingSw.js. The client index embeds this object as serviceWorker so a single workflow covers both surfaces.
  • Signed service worker manifestngsw.json lists SHA-256 hashes for every production asset and is signed using an ECDSA P-521 key. The detached signature lives at /manifestSignature and the public JWK at /codeSignPublicKey.jwk.

Releases use the format <package version>-<UTC date> (for example 0.20.7-20250105). The latest.json pointer always indicates which release CloudFront is currently serving.

Download & Inspect the Source Snapshot

Use the quick workflow below to obtain the same client source that is powering production:

  1. Fetch https://safe.unolock.com/transparency/latest.json to obtain the current release id.
  2. Download the source archive, build-info, and manifest references listed in that JSON.
  3. Extract the archive locally so you can audit or build it in a clean environment.
curl -s https://safe.unolock.com/transparency/latest.json | tee latest.json
RELEASE=$(jq -r '.release' latest.json)
curl -O https://safe.unolock.com/transparency/$RELEASE/source.tar.gz
tar -xzf source.tar.gz

This snapshot matches the commit recorded in build-info.json. Because it is generated via git archive, there are no build products or hidden files— what you unpack is exactly what CodeBuild compiled. You can diff it against local work, audit dependencies, or reproduce a release build.

Verify the Build & Production Assets

  • Compare the commit hash in build-info.json with your local checkout or GitHub mirror.
  • Use the paths in index.json to pull ngsw.json, manifestSignature, and codeSignPublicKey.jwk.
  • Validate the SHA-256 hashes inside ngsw.json against the assets you fetch from CloudFront.
  • Verify the detached signature using any ECDSA P-521 capable library to prove that Techsologic produced the manifest.

The signed manifest is the security boundary: if the signature and hashes are intact, the client files you downloaded are the exact bits served in production. Our VERIFYING_PRODUCTION.md guide (available inside the root of every source snapshot) walks through the full validation workflow end-to-end.

Service Worker Transparency

The service worker ships from its own repository and release cadence. For every client release we republish the corresponding service worker bundle under /transparency/service-worker/<release>/ and surface its object in the main index.json. This lets you audit the offline caching logic, signing hooks, and background crypto separately while still tying it to the client build you downloaded.

The service worker artifact additionally includes the SHA-256 hash of /signingSw.js, so checking one file is enough to ensure your fetch matches the published digest.

Fail-Closed Signing Guarantees

Production deploys can only happen with a valid signing key. The build step that emits manifestSignature calls signAppFiles.js, which aborts if keys are missing or placeholders. Key generation only runs when ALLOW_KEYGEN=1 is set explicitly, so CodeBuild/CodePipeline cannot silently ship unsigned assets. If a signing issue occurs, the pipeline fails and no new files reach CloudFront.

Together with the transparency bundle, this gives independent reviewers enough information to clone the deployed client, verify its provenance, and keep UnoLock accountable to the community.