git-launcher: rename trusted workload launcher

Author: h4x3rotab

…ws/trusted-workload-launcher-release.yml …ithub/workflows/git-launcher-release.yml.github/workflows/trusted-workload-launcher-release.yml renamed to .github/workflows/git-launcher-release.yml .github/workflows/trusted-workload-launcher-release.yml renamed to .github/workflows/git-launcher-release.yml

@@ -1,9 +1,9 @@
-name: trusted-workload-launcher Release
+name: git-launcher Release
 on:
   workflow_dispatch: {}
   push:
     tags:
-      - 'trusted-workload-launcher-v*'
+      - 'git-launcher-v*'
 
 permissions:
   contents: write
@@ -16,14 +16,14 @@ jobs:
     runs-on: ubuntu-latest
     env:
       IMAGE_REGISTRY: docker.io
-      IMAGE_REPOSITORY: ${{ vars.DOCKERHUB_ORG }}/trusted-workload-launcher
+      IMAGE_REPOSITORY: ${{ vars.DOCKERHUB_ORG }}/git-launcher
     steps:
       - name: Checkout repository
         uses: actions/checkout@v4
 
       - name: Parse version from tag
         run: |
-          VERSION=${GITHUB_REF#refs/tags/trusted-workload-launcher-v}
+          VERSION=${GITHUB_REF#refs/tags/git-launcher-v}
           if [ -z "${VERSION}" ]; then
             echo "Unable to parse version from ref: ${GITHUB_REF}" >&2
             exit 1
@@ -33,7 +33,7 @@ jobs:
           echo "Parsed version: ${VERSION}"
 
       - name: Run launcher tests
-        working-directory: trusted-workload-launcher
+        working-directory: git-launcher
         run: ./tests/run-tests.sh
 
       - name: Set up Docker Buildx
@@ -50,21 +50,21 @@ jobs:
         id: build-and-push
         uses: docker/build-push-action@v5
         with:
-          context: trusted-workload-launcher
-          file: trusted-workload-launcher/docker/Dockerfile
+          context: git-launcher
+          file: git-launcher/docker/Dockerfile
           push: true
-          tags: docker.io/${{ vars.DOCKERHUB_ORG }}/trusted-workload-launcher:${{ env.VERSION }}
+          tags: docker.io/${{ vars.DOCKERHUB_ORG }}/git-launcher:${{ env.VERSION }}
           platforms: linux/amd64
           labels: |
-            org.opencontainers.image.title=trusted-workload-launcher
+            org.opencontainers.image.title=git-launcher
             org.opencontainers.image.source=${{ github.server_url }}/${{ github.repository }}
             org.opencontainers.image.revision=${{ github.sha }}
             org.opencontainers.image.version=${{ env.VERSION }}
 
       - name: Generate artifact attestation
         uses: actions/attest-build-provenance@v1
         with:
-          subject-name: docker.io/${{ vars.DOCKERHUB_ORG }}/trusted-workload-launcher
+          subject-name: docker.io/${{ vars.DOCKERHUB_ORG }}/git-launcher
           subject-digest: ${{ steps.build-and-push.outputs.digest }}
           push-to-registry: true
 
@@ -74,7 +74,7 @@ jobs:
           IMAGE_DIGEST: ${{ steps.build-and-push.outputs.digest }}
         run: |
           {
-            echo "## trusted-workload-launcher image"
+            echo "## git-launcher image"
             echo ""
             echo "- Tag: \`${IMAGE_REFERENCE}\`"
             echo "- Digest: \`${IMAGE_DIGEST}\`"
@@ -85,7 +85,7 @@ jobs:
         uses: softprops/action-gh-release@v1
         with:
           body: |
-            ## trusted-workload-launcher image (SHA256)
+            ## git-launcher image (SHA256)
 
             - Image: `${{ env.IMAGE_REFERENCE }}`
             - Digest: `${{ steps.build-and-push.outputs.digest }}`

README.md

@@ -231,7 +231,7 @@ Implementation details and infrastructure patterns.
 | Example | Description |
 |---------|-------------|
 | [launcher](./launcher) | Generic launcher pattern for Docker Compose apps (auto-update) |
-| [trusted-workload-launcher](./trusted-workload-launcher) | Run a pinned Git commit in a TEE. |
+| [git-launcher](./git-launcher) | Run a pinned Git commit in a TEE. |
 | [prelaunch-script](./prelaunch-script) | Pre-launch script patterns (Phala Cloud) |
 | [private-docker-image-deployment](./private-docker-image-deployment) | Using private Docker registries |
 | [attestation/rtmr3-based](./attestation/rtmr3-based) | RTMR3-based attestation (legacy) |

trusted-workload-launcher/.dockerignore git-launcher/.dockerignoretrusted-workload-launcher/.dockerignore renamed to git-launcher/.dockerignore

@@ -1,17 +1,16 @@
-# trusted-workload-launcher
+# git-launcher
 
-A minimal, auditable launcher image for dstack. Given a config file that
+A minimal, auditable Git launcher image for dstack. Given a config file that
 names an upstream Git repo and a full commit SHA, the launcher fetches that
 exact commit, verifies `HEAD` after checkout, and runs the workload's own
 entry point script — with no fallback to branches, tags, or short SHAs.
 
-"Trusted" in the name refers to what a dstack deployment using this image
-can produce — a *trusted workload deployment* — not to any intrinsic
-property of the workload code. The launcher's job is to make the identity
-of what runs in the TEE checkable: it combines TEE attestation with an
-auditable image digest and an attested config that names the workload
-commit. Whether the workload at that commit is itself trustworthy is up to
-the auditor.
+The name is literal: this image launches arbitrary Git input, but only at an
+explicit commit selected by attested config. It does not make the workload
+trustworthy by itself. Its job is to make the identity of what runs in the TEE
+checkable by combining TEE attestation, an auditable launcher image digest, and
+an attested config that names the workload commit. Whether the workload at that
+commit is itself trustworthy is up to the auditor.
 
 By convention, **the workload repo provides its own bash entry point at
 `entrypoint.sh`** (default mode). This keeps install/build/run logic inside
@@ -109,10 +108,10 @@ given (launcher image digest, attested config) pair.
 ## CLI
 
 ```
-trusted-workload-launcher <config-file>
+git-launcher <config-file>
 ```
 
-The launcher is a single bash script (`bin/trusted-workload-launcher`). It
+The launcher is a single bash script (`bin/git-launcher`). It
 depends only on `bash`, `git`, and POSIX coreutils. It is **not** sourced
 and **does not source** the config. In default mode, the only bytes it
 executes are those of the workload repo's `entrypoint.sh` at the pinned
@@ -191,14 +190,28 @@ audited alongside `COMMIT_SHA`.
   mode it executes `INSTALL_CMD` / `RUN_CMD` via `bash -c`. Nothing else
   from the config reaches a shell.
 
+### Persistent volume and reboot behavior
+
+`WORK_DIR` should normally live on a persistent Docker volume, for example
+`/var/lib/git-launcher/<workload>`. On first boot, `git-launcher` creates the
+directory and clones `REPO_URL` there. On reboot or container restart, the same
+directory is reused only if it is already a git checkout whose `origin` exactly
+matches `REPO_URL`.
+
+Every boot still runs the same verification path: fetch from `origin`, detach
+checkout to `COMMIT_SHA`, then assert `git rev-parse HEAD == COMMIT_SHA`.
+Persistent state is therefore only a cache. It does not decide what runs. If
+the volume is empty, the launcher reclones. If the volume is non-empty but not a
+git checkout, or if it points at a different origin, startup fails.
+
 ## Example
 
 See [`examples/web-app.conf`](./examples/web-app.conf). Adapt `REPO_URL`,
 `COMMIT_SHA`, and (if you need it) `REPO_SUBDIR` for your workload, and
 make sure the workload repo has a `entrypoint.sh` at the pinned commit.
 
 ```sh
-./bin/trusted-workload-launcher ./examples/web-app.conf
+./bin/git-launcher ./examples/web-app.conf
 ```
 
 The launcher logs the resolved repo, commit, workdir, and selected mode at
@@ -235,11 +248,11 @@ reflected in the dstack attestation.
 ```yaml
 services:
   workload:
-    image: docker.io/<org>/trusted-workload-launcher@sha256:<launcher-digest>
-    command: ["/etc/trusted-workload-launcher/config.conf"]
+    image: docker.io/<org>/git-launcher@sha256:<launcher-digest>
+    command: ["/etc/git-launcher/config.conf"]
     volumes:
-      - ./web-app.conf:/etc/trusted-workload-launcher/config.conf:ro
-      - workload-checkout:/var/lib/trusted-workload-launcher
+      - ./web-app.conf:/etc/git-launcher/config.conf:ro
+      - workload-checkout:/var/lib/git-launcher
       - /var/run/dstack.sock:/var/run/dstack.sock
     restart: unless-stopped
 
@@ -257,13 +270,13 @@ against the one they audited:
 ```yaml
 services:
   workload:
-    image: docker.io/<org>/trusted-workload-launcher@sha256:<launcher-digest>
-    command: ["/etc/trusted-workload-launcher/config.conf"]
+    image: docker.io/<org>/git-launcher@sha256:<launcher-digest>
+    command: ["/etc/git-launcher/config.conf"]
     configs:
       - source: pin
-        target: /etc/trusted-workload-launcher/config.conf
+        target: /etc/git-launcher/config.conf
     volumes:
-      - workload-checkout:/var/lib/trusted-workload-launcher
+      - workload-checkout:/var/lib/git-launcher
       - /var/run/dstack.sock:/var/run/dstack.sock
     restart: unless-stopped
 
@@ -272,7 +285,7 @@ configs:
     content: |
       REPO_URL=https://github.com/example-org/example-web-app.git
       COMMIT_SHA=<full-40-or-64-hex-sha>
-      WORK_DIR=/var/lib/trusted-workload-launcher/example-web-app
+      WORK_DIR=/var/lib/git-launcher/example-web-app
 
 volumes:
   workload-checkout:
@@ -288,9 +301,9 @@ If you want a single digest to fully determine the workload, build a small
 downstream image that copies the config in:
 
 ```dockerfile
-FROM docker.io/<org>/trusted-workload-launcher@sha256:<launcher-digest>
-COPY web-app.conf /etc/trusted-workload-launcher/config.conf
-CMD ["/etc/trusted-workload-launcher/config.conf"]
+FROM docker.io/<org>/git-launcher@sha256:<launcher-digest>
+COPY web-app.conf /etc/git-launcher/config.conf
+CMD ["/etc/git-launcher/config.conf"]
 ```
 
 Deploy that derived image (pinned by its own `@sha256:…`). The derived
@@ -331,11 +344,11 @@ unprivileged in CI or on a developer laptop.
 
 ## Release image provenance
 
-The release workflow (`.github/workflows/trusted-workload-launcher-release.yml`
+The release workflow (`.github/workflows/git-launcher-release.yml`
 in this repository's root `.github/`) follows the dstack-examples pattern:
 
 1. run `./tests/run-tests.sh`;
-2. build and push `docker.io/${DOCKERHUB_ORG}/trusted-workload-launcher:<tag>`;
+2. build and push `docker.io/${DOCKERHUB_ORG}/git-launcher:<tag>`;
 3. call `actions/attest-build-provenance@v1` with the Docker build digest;
 4. write the digest and a Sigstore search link into both the GitHub Actions
    step summary and the GitHub release body.
@@ -349,7 +362,7 @@ compare that digest before trusting the launcher image.
 If you are reviewing this directory at commit `L` before signing off on a
 launcher image, the relevant audit surface is:
 
-1. `bin/trusted-workload-launcher` — every line. Confirm:
+1. `bin/git-launcher` — every line. Confirm:
    * No `eval`, no `source`/`.`, no command substitution applied to config
      values during parsing.
    * `git checkout` always uses the verbatim `COMMIT_SHA` and the result is

trusted-workload-launcher/README.md git-launcher/README.mdtrusted-workload-launcher/README.md renamed to git-launcher/README.md

@@ -1,7 +1,7 @@
-# Verifying a trusted-workload-launcher deployment
+# Verifying a git-launcher deployment
 
 How a relying party verifies that a dstack CVM is running
-`trusted-workload-launcher` and that the workload commit executed inside the
+`git-launcher` and that the workload commit executed inside the
 TEE is the one they audited.
 
 ## Quick path (default mode, 4 steps)
@@ -170,7 +170,7 @@ command and assert equality:
 A one-shot reference-comparison script looks roughly like this:
 
 ```sh
-expected_image=docker.io/<org>/trusted-workload-launcher@sha256:<L>
+expected_image=docker.io/<org>/git-launcher@sha256:<L>
 expected_compose_hash=$(sha256sum < audited-app_compose.json | awk '{print $1}')
 expected_mrtd=<from dstack release notes>
 expected_rtmr0=<from dstack release notes>
@@ -197,7 +197,7 @@ into `rtmr3` if your verifier supports it.
 
 ### 3. Verify launcher image provenance via Sigstore
 
-The `trusted-workload-launcher-release.yml` workflow publishes an
+The `git-launcher-release.yml` workflow publishes an
 `actions/attest-build-provenance` attestation bound to the pushed image
 digest. The attestation is not a claim of bit-for-bit reproducibility — it
 is a signed statement that *this* OCI digest was produced by *this*
@@ -207,7 +207,7 @@ the GitHub OIDC identity.
 ```sh
 gh attestation verify \
   --owner Dstack-TEE \
-  oci://docker.io/<org>/trusted-workload-launcher@sha256:<L>
+  oci://docker.io/<org>/git-launcher@sha256:<L>
 ```
 
 or equivalently with `cosign verify-attestation` against
@@ -219,7 +219,7 @@ or equivalently with `cosign verify-attestation` against
 
 That commit is the source of truth for the launcher's bytes. Treat the
 Sigstore attestation as the chain of custody from the
-`trusted-workload-launcher/` source at that commit to the deployed image
+`git-launcher/` source at that commit to the deployed image
 digest.
 
 If you want to go further you can rebuild the image from that commit and
@@ -266,10 +266,10 @@ during config summary, then the checkout/verify lines, then the `exec`
 line, so they appear in this order):
 
 ```
-[trusted-workload-launcher] mode:     default (workload repo entrypoint.sh)
-[trusted-workload-launcher] checking out <COMMIT_SHA>
-[trusted-workload-launcher] HEAD verified: <COMMIT_SHA>
-[trusted-workload-launcher] exec in <WORK_DIR>[/<REPO_SUBDIR>]: bash entrypoint.sh
+[git-launcher] mode:     default (workload repo entrypoint.sh)
+[git-launcher] checking out <COMMIT_SHA>
+[git-launcher] HEAD verified: <COMMIT_SHA>
+[git-launcher] exec in <WORK_DIR>[/<REPO_SUBDIR>]: bash entrypoint.sh
 ```
 
 Advanced mode logs `mode: advanced (RUN_CMD)` early on, and the last
@@ -292,7 +292,7 @@ suite. The compose-hash binding it demonstrates is identical:
 
 | Field | Value |
 | --- | --- |
-| Launcher image | `docker.io/h4x3rotab/trusted-workload-launcher-smoke@sha256:0d3f2dbda5e6ae9513ea4e8e69dcbc87c1f3af29744f0e36b9814685e5739866` |
+| Launcher image | `docker.io/h4x3rotab/git-launcher-smoke@sha256:0d3f2dbda5e6ae9513ea4e8e69dcbc87c1f3af29744f0e36b9814685e5739866` |
 | Compose pattern | inline `configs:` with `content:` block carrying the launcher config |
 | Workload repo | `https://github.com/octocat/Hello-World.git` |
 | Pinned commit | `7fd1a60b01f91b314f59955a4e4d4e80d8edf11d` |
@@ -310,16 +310,16 @@ get a different attestation.
 the expected launcher digest. `phala logs --cvm-id <id>` showed:
 
 ```
-[trusted-workload-launcher] checking out 7fd1a60b01f91b314f59955a4e4d4e80d8edf11d
-[trusted-workload-launcher] HEAD verified: 7fd1a60b01f91b314f59955a4e4d4e80d8edf11d
-[trusted-workload-launcher] exec in /var/lib/trusted-workload-launcher/hello: ...
-TWL_PINNED_HEAD=7fd1a60b01f91b314f59955a4e4d4e80d8edf11d
-TWL_README_BYTES=13
-TWL_READY
+[git-launcher] checking out 7fd1a60b01f91b314f59955a4e4d4e80d8edf11d
+[git-launcher] HEAD verified: 7fd1a60b01f91b314f59955a4e4d4e80d8edf11d
+[git-launcher] exec in /var/lib/git-launcher/hello: ...
+GIT_LAUNCHER_PINNED_HEAD=7fd1a60b01f91b314f59955a4e4d4e80d8edf11d
+GIT_LAUNCHER_README_BYTES=13
+GIT_LAUNCHER_READY
 ```
 
-`TWL_PINNED_HEAD` is from `git rev-parse HEAD` evaluated *inside the TEE
-container* by the workload's `RUN_CMD`, so it is independent
+`GIT_LAUNCHER_PINNED_HEAD` is from `git rev-parse HEAD` evaluated *inside
+the TEE container* by the workload's `RUN_CMD`, so it is independent
 corroboration that the bytes running are the pinned commit.
 
 ## Limitations

trusted-workload-launcher/VERIFY.md git-launcher/VERIFY.mdtrusted-workload-launcher/VERIFY.md renamed to git-launcher/VERIFY.md

@@ -1,5 +1,5 @@
 #!/usr/bin/env bash
-# trusted-workload-launcher: minimal launcher for a workload pinned at a
+# git-launcher: minimal launcher for a workload pinned at a
 # specific upstream Git commit.
 #
 # Reads one env-file config, clones the configured repo, hard-pins to the

…d-launcher/bin/trusted-workload-launcher git-launcher/bin/git-launchertrusted-workload-launcher/bin/trusted-workload-launcher renamed to git-launcher/bin/git-launcher trusted-workload-launcher/bin/trusted-workload-launcher renamed to git-launcher/bin/git-launcher

@@ -13,7 +13,7 @@ RUN apt-get update \
         openssh-client \
     && rm -rf /var/lib/apt/lists/*
 
-COPY bin/trusted-workload-launcher /usr/local/bin/trusted-workload-launcher
-RUN chmod 0755 /usr/local/bin/trusted-workload-launcher
+COPY bin/git-launcher /usr/local/bin/git-launcher
+RUN chmod 0755 /usr/local/bin/git-launcher
 
-ENTRYPOINT ["trusted-workload-launcher"]
+ENTRYPOINT ["git-launcher"]

…sted-workload-launcher/docker/Dockerfile git-launcher/docker/Dockerfiletrusted-workload-launcher/docker/Dockerfile renamed to git-launcher/docker/Dockerfile trusted-workload-launcher/docker/Dockerfile renamed to git-launcher/docker/Dockerfile

@@ -26,7 +26,7 @@
 
 REPO_URL=https://github.com/example-org/example-web-app.git
 COMMIT_SHA=0000000000000000000000000000000000000000
-WORK_DIR=/var/lib/trusted-workload-launcher/example-web-app
+WORK_DIR=/var/lib/git-launcher/example-web-app
 
 # Optional: cd into a subdirectory of the upstream repo before exec'ing
 # entrypoint.sh. Useful if the workload lives in a monorepo subpath.
@@ -41,7 +41,7 @@ WORK_DIR=/var/lib/trusted-workload-launcher/example-web-app
 # environment of entrypoint.sh. Use this for runtime configuration (listen
 # address, secrets, etc.) — keeping it separate from the pin config means
 # config-only edits do not perturb the trust-bearing fields above.
-# CHILD_ENV_FILE=/etc/trusted-workload-launcher/web-app.env
+# CHILD_ENV_FILE=/etc/git-launcher/web-app.env
 
 # Advanced mode (use only if the workload repo cannot host its own
 # entrypoint.sh — e.g. you are pinning a third-party repo unchanged):