consolidate dstack cap (s/DStack|Dstack/dstack/g)

Author: h4x3rotab

attestation.md

@@ -1,6 +1,6 @@
-# TEE Attestation Guide for DStack Applications
+# TEE Attestation Guide for dstack Applications
 
-This document outlines the process of verifying the authenticity and integrity of data produced by DStack Applications running within Intel TDX environments.
+This document outlines the process of verifying the authenticity and integrity of data produced by dstack Applications running within Intel TDX environments.
 
 ## 1. Review code safety
 
@@ -11,28 +11,28 @@ This document outlines the process of verifying the authenticity and integrity o
 ## 2. Validate data origin authenticity
 ### 2.1 Understanding tdx quote measurements
 
-Applications generate a tdx quote using Dstack's API given the data they want to prove.
+Applications generate a tdx quote using dstack's API given the data they want to prove.
 
 The quote signature can be verified using dcap-qvl to confirm its generation by a legitimate TDX CVM and environment trustworthiness.
 Following signature verification, examine MRTD and RTMRs to confirm the CVM is executing the verified code.
 
 The MR register values indicate the following:
 
-- MRTD: Contains the virtual firmware measurement, taken by TDX-module in SEAM mode. Virtual firmware (OVMF in Dstack's case) is the first code executed post-CVM startup, serving as the App code's trust anchor. Intel signs and guarantees TDX-module integrity.
+- MRTD: Contains the virtual firmware measurement, taken by TDX-module in SEAM mode. Virtual firmware (OVMF in dstack's case) is the first code executed post-CVM startup, serving as the App code's trust anchor. Intel signs and guarantees TDX-module integrity.
 
-- RTMR: Measurements recorded by code executing within the CVM. In Dstack OS, these measurements are defined as:
+- RTMR: Measurements recorded by code executing within the CVM. In dstack OS, these measurements are defined as:
 
-    - RTMR0: OVMF records CVM's virtual hardware setup, including CPU count, memory size, and device configuration. While Dstack uses fixed devices, CPU and memory specifications can vary. RTMR0 can be computed from these specifications.
+    - RTMR0: OVMF records CVM's virtual hardware setup, including CPU count, memory size, and device configuration. While dstack uses fixed devices, CPU and memory specifications can vary. RTMR0 can be computed from these specifications.
     - RTMR1: OVMF records the Linux kernel measurement.
     - RTMR2: Linux kernel records kernel cmdline (including rootfs hash) and initrd measurements.
-    - RTMR3: initrd records Dstack App details, including compose hash, instance id, app id, rootfs hash, and key provider.
+    - RTMR3: initrd records dstack App details, including compose hash, instance id, app id, rootfs hash, and key provider.
 
 MRTD, RTMR0, RTMR1, and RTMR2 can be pre-calculated from the built image (given CPU+RAM specifications). Compare these with the verified quote's MRs to confirm correct base image code execution.
 
 RTMR3 differs as it contains runtime information like compose hash and instance id. Verify this by replaying the event log - if the calculated RTMR3 matches the quote's RTMR3, the event log information is valid. Then verify the compose hash, key provider, and other event log details match expectations.
 
 ### 2.2. Determining expected MRs
-MRTD, RTMR0, RTMR1, and RTMR2 correspond to the image. Dstack OS builds all related software from source.
+MRTD, RTMR0, RTMR1, and RTMR2 correspond to the image. dstack OS builds all related software from source.
 Build version v0.4.0 using these commands:
 ```bash
 git clone https://github.com/Dstack-TEE/meta-dstack.git
@@ -59,7 +59,7 @@ Once these verification steps are completed successfully, the report_data contai
 
 ## Conclusion
 
-To verify Dstack App data trustworthiness:
+To verify dstack App data trustworthiness:
 
 - Review source code for correctness and safety.
 - Build image from source.

basefiles/dstack-guest-agent.service

@@ -1,5 +1,5 @@
 [Unit]
-Description=Dstack Guest Agent Service
+Description=dstack Guest Agent Service
 After=network.target tboot.service
 Before=docker.service
 

basefiles/dstack-prepare.service

@@ -1,5 +1,5 @@
 [Unit]
-Description=DStack Guest Preparation Service
+Description=dstack Guest Preparation Service
 After=network.target chronyd.service
 Before=app-compose.service dstack-guest-agent.service docker.service
 OnFailure=reboot.target

docs/deployment.md

@@ -1,14 +1,14 @@
-# Deployment of DStack
+# Deployment of dstack
 
-This document describes the deployment of DStack components on bare metal TDX hosts.
+This document describes the deployment of dstack components on bare metal TDX hosts.
 It contains steps to deploy dstack-kms and dstack-gateway into CVMs.
 
 ## Prerequisites
 
 - Follow the [TDX setup guide](https://github.com/canonical/tdx) to setup the TDX host.
 - Install `cargo` and `rustc`
 
-## Clone the DStack repository
+## Clone the dstack repository
 ```bash
 git clone https://github.com/Dstack-TEE/dstack
 ```
@@ -229,7 +229,7 @@ MY_URL=https://gateway.test2.dstack.phala.network:9202
 # Bootnode URL. If you want to deploy a multi-node dstack-gateway cluster, set the bootnode URL to the URL of another node already deployed or planed to be deployed later.
 BOOTNODE_URL=https://gateway.test2.dstack.phala.network:9202
 
-# DStack OS image name
+# dstack OS image name
 OS_IMAGE=dstack-0.5.2
 
 # Set defaults for variables that might not be in .env
@@ -296,10 +296,10 @@ After the dstack-vmm is ready, you can deploy an app on it following the steps b
 
 The on-chain registration process includes two steps:
 
-1. Deploy an App's control contract DstackApp. Developers can develop their own or choose the reference contract from the Dstack repository. Custom contracts need to implement the IAppAuth interface.
+1. Deploy an App's control contract DstackApp. Developers can develop their own or choose the reference contract from the dstack repository. Custom contracts need to implement the IAppAuth interface.
 2. Call DstackKms.registerApp(appContractAddress) to register the contract.
 
-The Dstack repository provides scripts to complete these two steps:
+The dstack repository provides scripts to complete these two steps:
 
 **Option 1: Traditional deployment (2 transactions)**
 ```bash

docs/design-and-hardening-decisions.md

@@ -10,7 +10,7 @@ The meta-dstack layer is designed to create a minimally secure image for booting
 
 **Decision**: We use `linux-yocto-dev` (development recipes) instead of `linux-yocto` (stable recipes).
 
-**Rationale**: We use Scarthgap version of Yocto, which is the latest version when we started the Dstack project. The stable `linux-yocto` recipe in Scarthgap is based on kernel 6.6 which does not support RTMR[1-2]. So we switch to `linux-yocto-dev` to get the kernel 6.9 support. The latest released Yocto (Walnascar) updated kernel to 6.12 which meets our requirements. We plan to upgrade the Yocto version later, but this is not trivial as all downstream Yocto recipes need to be updated to adapt to the major Yocto version change.
+**Rationale**: We use Scarthgap version of Yocto, which is the latest version when we started the dstack project. The stable `linux-yocto` recipe in Scarthgap is based on kernel 6.6 which does not support RTMR[1-2]. So we switch to `linux-yocto-dev` to get the kernel 6.9 support. The latest released Yocto (Walnascar) updated kernel to 6.12 which meets our requirements. We plan to upgrade the Yocto version later, but this is not trivial as all downstream Yocto recipes need to be updated to adapt to the major Yocto version change.
 
 ### 2. TDVF vs td-shim Boot Firmware
 
@@ -49,7 +49,7 @@ See [here](https://intel.github.io/ccc-linux-guest-hardening-docs/security-spec.
 
 ### 5. Secure System Time
 
-**Implementation**: Dstack OS enforces the guest kernel uses TSC as the only timer source by appending `tsc=reliable no-kvmclock` to the kernel cmdline. It also enforces the use of NTS with built-in [trusted servers](https://github.com/Dstack-TEE/meta-dstack/blob/bef2dfa850f4116ae4ece96d8c0948965c5874b3/meta-dstack/recipes-core/chrony/files/chrony.conf#L13-L20) to synchronize system time.
+**Implementation**: dstack OS enforces the guest kernel uses TSC as the only timer source by appending `tsc=reliable no-kvmclock` to the kernel cmdline. It also enforces the use of NTS with built-in [trusted servers](https://github.com/Dstack-TEE/meta-dstack/blob/bef2dfa850f4116ae4ece96d8c0948965c5874b3/meta-dstack/recipes-core/chrony/files/chrony.conf#L13-L20) to synchronize system time.
 
 **Behavior**: When `secure_time` is enabled in the app-compose.json configuration, the system ensures time synchronization is completed before requesting application keys. If `secure_time` is disabled, time synchronization is not enforced before application launch.
 

docs/security-guide/cvm-boundaries.md

@@ -1,16 +1,16 @@
-This document describes the Dstack defined information exchange channels between CVM and the outside world.
+This document describes the dstack defined information exchange channels between CVM and the outside world.
 
 ## Network layer
 
 ### Virtual Native Network
-Dstack currently uses QEMU's user-mode network stack to create a virtual network for the CVM. In this setup, QEMU (running on the host) simulates the gateway, DNS, and DHCP services. The CVM should treat these network components as untrusted.
+dstack currently uses QEMU's user-mode network stack to create a virtual network for the CVM. In this setup, QEMU (running on the host) simulates the gateway, DNS, and DHCP services. The CVM should treat these network components as untrusted.
 
 ### Wireguard Network
 When dstack-gateway is enabled, it establishes a secure Wireguard network connection between the workload CVM and dstack-gateway CVM.
 External clients connect to the workload CVM through dstack-gateway using the CVM's ZT-HTTPS domain. For clients, ZT-HTTPS ensures no man-in-the-middle attacks can occur between them and the workload CVM. However, workload developers should note that incoming traffic might come from either dstack-gateway or the QEMU native network.
 
 ## Host Shared Folder
-Dstack OS requires a host shared folder to be attached to the CVM. It copies the following files from the host shared folder to the CVM:
+dstack OS requires a host shared folder to be attached to the CVM. It copies the following files from the host shared folder to the CVM:
 
 | File | Purpose |
 |------|--------|
@@ -82,7 +82,7 @@ The hash of this file is not extended to any RTMR because each field has its own
 It does not make sense to measure the entire sys-config.json, because it is not deterministic and measuring it would make the verification process troublesome.
 
 ### .encrypted-env
-Dstack uses encrypted environment variables to allow app developers to securely load sensitive configuration values into the CVM. Since these variables are temporarily stored on the host server before being loaded into the CVM, encryption ensures host servers cannot access the confidential data.
+dstack uses encrypted environment variables to allow app developers to securely load sensitive configuration values into the CVM. Since these variables are temporarily stored on the host server before being loaded into the CVM, encryption ensures host servers cannot access the confidential data.
 
 #### Encryption Workflow:
 
@@ -116,13 +116,13 @@ Dstack uses encrypted environment variables to allow app developers to securely
 This file is not measured to RTMRs. But it is highly recommended to add application-specific integrity checks on encrypted environment variables at the application layer. See [security-guide.md](security-guide.md) for more details.
 
 ### .user-config
-This is an optional application-specific configuration file that applications inside the CVM can access. Dstack OS simply stores it at /dstack/user-config without any measurement or additional processing.
+This is an optional application-specific configuration file that applications inside the CVM can access. dstack OS simply stores it at /dstack/user-config without any measurement or additional processing.
 
 Application developers should perform integrity checks on user_config at the application layer if necessary.
 
 ## APIs
 
-Dstack provides several API services for communication between components. These APIs define the boundaries and information exchange channels between the CVM and external systems.
+dstack provides several API services for communication between components. These APIs define the boundaries and information exchange channels between the CVM and external systems.
 
 ### VSOCK-based Guest API Service
 

docs/security-guide/security-guide.md

@@ -1,4 +1,4 @@
-# Dstack Production Security Best Practices
+# dstack Production Security Best Practices
 
 This document describes security considerations for deploying dstack apps in production.
 
@@ -30,11 +30,11 @@ services:
 
 ## Reproducibility
 
-If your App is intended for end users who need to verify what code your App is running, then the verifiability of Docker images is crucial. Dstack anchors the code running inside the CVM through the hash of app-compose.json. However, at the same time, the App needs to provide users with a reproducible build method. There are multiple ways to achieve reproducible image builds, and dstack provides a reference example: [dstack-ingress](https://github.com/Dstack-TEE/dstack-examples/tree/main/custom-domain/dstack-ingress)
+If your App is intended for end users who need to verify what code your App is running, then the verifiability of Docker images is crucial. dstack anchors the code running inside the CVM through the hash of app-compose.json. However, at the same time, the App needs to provide users with a reproducible build method. There are multiple ways to achieve reproducible image builds, and dstack provides a reference example: [dstack-ingress](https://github.com/Dstack-TEE/dstack-examples/tree/main/custom-domain/dstack-ingress)
 
 ## Authenticated envs and user_config
 
-Dstack provides encrypted environment variable functionality. Although the CVM physical machine controller cannot view encrypted environment variables, they may forge encrypted environment variables because the CVM encryption public key is known to everyone. Therefore, Apps need to perform auth checks on encrypted environment variables at the application layer. LAUNCH_TOKEN pattern is one method to prevent unauthorized envs replacement. For details, refer to the deployment script of [dstack-gateway](https://github.com/Dstack-TEE/dstack/blob/1b8a4516826b02f9d7f747eddac244dcd68fc325/gateway/dstack-app/deploy-to-vmm.sh#L150-L165).
+dstack provides encrypted environment variable functionality. Although the CVM physical machine controller cannot view encrypted environment variables, they may forge encrypted environment variables because the CVM encryption public key is known to everyone. Therefore, Apps need to perform auth checks on encrypted environment variables at the application layer. LAUNCH_TOKEN pattern is one method to prevent unauthorized envs replacement. For details, refer to the deployment script of [dstack-gateway](https://github.com/Dstack-TEE/dstack/blob/1b8a4516826b02f9d7f747eddac244dcd68fc325/gateway/dstack-app/deploy-to-vmm.sh#L150-L165).
 
 If you use dstack-vmm's built-in UI, the prelaunch script has already been automatically filled in for you:
 
@@ -79,7 +79,7 @@ Example app-compose.json:
 
 ## Don't expose unexpected ports
 
-In Dstack CVM, dstack-guest-agent listens on port 8090, allowing public access to basic CVM information.
+In dstack CVM, dstack-guest-agent listens on port 8090, allowing public access to basic CVM information.
 
 In docker-compose.yaml, all declared ports will be exposed to the public internet. Do not expose unnecessary ports.
 

dstack-mr/Cargo.toml

@@ -4,7 +4,7 @@ version.workspace = true
 authors.workspace = true
 edition.workspace = true
 license.workspace = true
-description = "A CLI tool for calculating TDX measurements for DStack images"
+description = "A CLI tool for calculating TDX measurements for dstack images"
 
 [dependencies]
 serde = { workspace = true, features = ["derive"] }

dstack-mr/cli/src/main.rs

@@ -30,7 +30,7 @@ struct MachineConfig {
     #[arg(short, long, default_value = "2G", value_parser = parse_memory_size)]
     memory: u64,
 
-    /// Path to DStack image metadata.json
+    /// Path to dstack image metadata.json
     metadata: PathBuf,
 
     /// Enable two-pass add pages

dstack-util/src/main.rs

@@ -30,7 +30,7 @@ mod parse_env_file;
 mod system_setup;
 mod utils;
 
-/// DStack guest utility
+/// dstack guest utility
 #[derive(Parser)]
 #[command(author, version, about)]
 struct Cli {