Conversation
puria
commented
Feb 4, 2026
- chore: remove useless thirdparty plugin example
- feat: add the temporal dev for ephemeral deploys
- fix: temporal service for ephemeral deployments
- fix: create /data folder
- oops
- let's remove the bind volumes
- add service names
- fix: add a healthcheck on the temporal service
- feat: add ephimeral docker files
- ooops wrong path
- oops wrong port
- no need for temporal up
- meh
- change to local server
- optional pat and get temporal from source
- need to check and run credimi binary not gow
There was a problem hiding this comment.
Pull request overview
This pull request adds ephemeral deployment configuration for the Credimi application and removes an unused thirdparty-simulator component. The changes introduce Docker and docker-compose configurations for temporary/ephemeral deployments that include Temporal workflow engine integration, along with supporting scripts and process management files.
Changes:
- Added ephemeral deployment infrastructure including Dockerfile.ephemeral, docker-compose.ephemeral.yml, and Procfile.ephemeral for temporary deployment environments
- Added entrypoint script for database seeding and data masking in ephemeral deployments
- Removed the entire thirdparty-simulator deployment directory and all associated files (Go code, dependencies, and Dockerfile)
Reviewed changes
Copilot reviewed 11 out of 12 changed files in this pull request and generated 12 comments.
Show a summary per file
| File | Description |
|---|---|
| scripts/ephemeral-entrypoint.sh | New entrypoint script for seeding and masking database in ephemeral deployments |
| docker-compose.ephemeral.yml | Docker Compose configuration for ephemeral Credimi service |
| deployment/docker-compose.temporal.ephemeral.yaml | Temporal service configuration for ephemeral deployments |
| Procfile.ephemeral | Process management file defining UI, API, and Temporal backend services |
| Dockerfile.ephemeral | Multi-stage Docker build for ephemeral deployments with all dependencies |
| deployment/thirdparty-simulator/* | Removed entire thirdparty simulator Go application and related files |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if command -v pinkmask >/dev/null 2>&1; then | ||
| masked_tmp="${data_db_path}.masked" | ||
| if [[ -n "${PINKMASK_ARGS:-}" ]]; then | ||
| pinkmask ${PINKMASK_ARGS} |
There was a problem hiding this comment.
The variable expansion syntax is incorrect. It should be unquoted in the PINKMASK_ARGS variable: pinkmask ${PINKMASK_ARGS} instead of pinkmask ${PINKMASK_ARGS}. When the variable is empty or contains multiple arguments, this will cause shell word splitting issues. The current quoted syntax will pass all arguments as a single string.
| - SERVICE_FQDN_CREDIMI | ||
| - SERVICE_FQDN_CREDIMI_8090 | ||
| - ADDRESS_UI=http://localhost:5100 | ||
| - ROOT_DIR=/app | ||
| - DATA_DB_PATH=/app/pb_data/data.db | ||
| - SEED_DB_PATH=/seed/pb_data/data.db | ||
| - PINKMASK_ARGS | ||
| - [email protected] | ||
| - MAESTRO_WORKER=${MAESTRO_WORKER:-https://android.credimi.io} | ||
| - TEMPORAL_ADDRESS=localhost:7233 | ||
| - PORT=5100 |
There was a problem hiding this comment.
Port configuration inconsistency: PORT is set to 5100, but SERVICE_FQDN_CREDIMI_8090 suggests the service should expose port 8090. Additionally, the ADDRESS_UI is set to localhost:5100 while the Procfile.ephemeral shows the API service running on 0.0.0.0:8090. This mismatch between configured ports will likely cause connectivity issues. The port configuration should be consistent across environment variables.
| # - pb_data_tmp:/app/pb_data | ||
| # - seed_db:${CREDIMI_SEED_DB}:ro | ||
| - /var/run/docker.sock:/var/run/docker.sock | ||
|
|
||
| # volumes: | ||
| # seed_db: |
There was a problem hiding this comment.
Commented-out volume configurations suggest incomplete implementation. The volumes for pb_data_tmp and seed_db are commented out but may be necessary for the ephemeral deployment to function correctly, especially given that the entrypoint script references SEED_DB_PATH. Either these volumes should be enabled with proper configuration, or the related code should be removed if they're not needed.
| # - pb_data_tmp:/app/pb_data | |
| # - seed_db:${CREDIMI_SEED_DB}:ro | |
| - /var/run/docker.sock:/var/run/docker.sock | |
| # volumes: | |
| # seed_db: | |
| - pb_data_tmp:/app/pb_data | |
| - seed_db:${CREDIMI_SEED_DB}:ro | |
| - /var/run/docker.sock:/var/run/docker.sock | |
| volumes: | |
| seed_db: |
| WORKDIR /app | ||
| RUN chmod +x /app/scripts/ephemeral-entrypoint.sh | ||
|
|
||
| HEALTHCHECK --interval=30s --timeout=10s --start-period=120s --retries=3 CMD curl --fail http://localhost:8090 || exit 1 |
There was a problem hiding this comment.
The healthcheck is configured to check localhost:8090, but the Procfile.ephemeral shows the API service binding to 0.0.0.0:8090 and PORT environment variable is set to 5100. There's inconsistency in which port the application actually runs on. The healthcheck should match the actual port where the service is accessible.
| HEALTHCHECK --interval=30s --timeout=10s --start-period=120s --retries=3 CMD curl --fail http://localhost:8090 || exit 1 | |
| HEALTHCHECK --interval=30s --timeout=10s --start-period=120s --retries=3 CMD curl --fail "http://localhost:${PORT:-8090}" || exit 1 |
| API: ./scripts/wait-for-it.sh -s -t 0 localhost:7233 && credimi serve --http=0.0.0.0:8090 | ||
| BE: temporal server start-dev --db-filename pb_data/temporal.db |
There was a problem hiding this comment.
The Temporal server in the Procfile starts with default port 7233 (via start-dev), but the deployment/docker-compose.temporal.ephemeral.yaml configures it to use port 7777. This creates a port conflict since both configurations are part of the ephemeral deployment setup. The Procfile.ephemeral BE process should align with the docker-compose configuration, or the docker-compose file should be removed if not used.
| API: ./scripts/wait-for-it.sh -s -t 0 localhost:7233 && credimi serve --http=0.0.0.0:8090 | |
| BE: temporal server start-dev --db-filename pb_data/temporal.db | |
| API: ./scripts/wait-for-it.sh -s -t 0 localhost:7777 && credimi serve --http=0.0.0.0:8090 | |
| BE: temporal server start-dev --frontend-port 7777 --db-filename pb_data/temporal.db |
| if command -v pinkmask >/dev/null 2>&1; then | ||
| masked_tmp="${data_db_path}.masked" | ||
| if [[ -n "${PINKMASK_ARGS:-}" ]]; then | ||
| pinkmask ${PINKMASK_ARGS} |
There was a problem hiding this comment.
The use of PINKMASK_ARGS in pinkmask ${PINKMASK_ARGS} allows arbitrary shell metacharacters to be interpreted, so if PINKMASK_ARGS is influenced by an attacker (e.g., via environment configuration), they can inject additional commands to run as the container user. For example, a value like "-i /tmp/foo -o /tmp/bar; rm -rf /" would cause the rm to execute after pinkmask. To fix this, avoid passing raw argument strings to the shell and instead restrict pinkmask options or parse them into a safe, fixed set of arguments before invocation.
| pinkmask ${PINKMASK_ARGS} | |
| # Validate that PINKMASK_ARGS contains only safe characters to avoid shell injection. | |
| # Allow letters, digits, space, dash, underscore, dot, and slash. | |
| if [[ "${PINKMASK_ARGS}" =~ [^a-zA-Z0-9_./\ -] ]]; then | |
| echo "Invalid characters detected in PINKMASK_ARGS; aborting masking step." >&2 | |
| exit 1 | |
| fi | |
| # Split PINKMASK_ARGS into an array of arguments and pass them safely to pinkmask. | |
| read -r -a pinkmask_args <<< "${PINKMASK_ARGS}" | |
| pinkmask "${pinkmask_args[@]}" |
| echo "🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥"; \ | ||
| echo "${CREDIMI_EXTRA_PAT}"; \ | ||
| echo "🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥"; \ |
There was a problem hiding this comment.
CREDIMI_EXTRA_PAT is echoed directly to the build output, which will leak this personal access token into Docker/CI logs and allow anyone with log access to reuse the credential. Since this token can likely access private repositories or other GitHub resources, an attacker who obtains the logs can impersonate the token owner. Remove these echo statements or mask/redact the token so it is never written to logs.
| echo "🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥"; \ | |
| echo "${CREDIMI_EXTRA_PAT}"; \ | |
| echo "🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥"; \ | |
| echo "Using CREDIMI_EXTRA_PAT for authenticated GitHub access"; \ |
| ENV GOMODCACHE=/gomod-cache | ||
| RUN --mount=type=cache,target=/gomod-cache --mount=type=cache,target=/go-cache go generate pkg/gen.go | ||
| RUN --mount=type=cache,target=/gomod-cache --mount=type=cache,target=/go-cache go build -o credimi main.go | ||
| RUN --mount=type=cache,target=/gomod-cache --mount=type=cache,target=/go-cache go install github.com/dyne/pinkmask/cmd/pinkmask@latest |
There was a problem hiding this comment.
go install github.com/dyne/pinkmask/cmd/pinkmask@latest pulls and builds arbitrary code from a third-party GitHub repository using the mutable latest reference, so if that repo or the latest reference is compromised the build will embed and later execute attacker-controlled code. Because this happens in an automated build with access to your source and artifacts, it is a classic supply-chain risk. To mitigate this, pin pinkmask to a specific immutable version (commit, tag, or checksum) and periodically review/upgrade it explicitly.
| ENV MISE_CACHE_DIR="/mise/cache" | ||
| ENV MISE_INSTALL_PATH="/usr/local/bin/mise" | ||
| ENV PATH="/mise/shims:$PATH" | ||
| RUN curl https://mise.run | sh |
There was a problem hiding this comment.
The command curl https://mise.run | sh executes a remote shell script from a third-party domain at build time without any integrity verification or pinning, giving that endpoint full control over the tools and binaries installed into this image. If the mise.run host, DNS, or TLS trust is compromised, an attacker can inject arbitrary code into your build and runtime image. Prefer installing mise via a pinned artifact (versioned URL with checksum/signature verification) or vendored installer so the downloaded content cannot be silently changed.
| RUN curl -sSL "https://temporal.download/cli/archive/latest?platform=linux&arch=amd64" -o /tmp/temporal.tar.gz \ | ||
| && tar -xzf /tmp/temporal.tar.gz -C /tmp \ | ||
| && mv /tmp/temporal /usr/local/bin/temporal \ | ||
| && chmod +x /usr/local/bin/temporal \ | ||
| && rm -f /tmp/temporal.tar.gz |
There was a problem hiding this comment.
The temporal CLI is downloaded from https://temporal.download/cli/archive/latest?platform=linux&arch=amd64 and installed without checksum or signature verification, and the latest endpoint is a mutable reference. If the download endpoint or the path behind latest is compromised, the image will embed and later execute an attacker-controlled temporal binary (e.g., when running temporal server start-dev). Pin this CLI to a specific immutable version and verify its integrity (checksum or signature) before installing.