Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

vmm-cli: encrypted env vars fail in three ways that all surface as "variable is required"

オープン
  • 何か問題がありますか？
#832 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
python
領域
backend, cli, security

調査の方向性

vmm-cli.py から始め、parse_env_file、deploy、update_vm_env、および生成された JSON を書き込む compose のパスを読みます。allowed_envs とホストおよびゲストの KMS URL がどのように設定されるかを追跡します。空または無効な env ファイルが明確に失敗し、compose で allowed_envs を設定でき、暗号化された env のワンステップデプロイで別々の KMS エンドポイントが維持されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Hit all three while deploying a CVM whose app needs one encrypted environment
variable — a DNS provider token. Each failed in a way that pointed somewhere
other than the actual cause, and together they cost about an hour and three
redeploys. Filing as one issue since they are all the same feature.

1. --env-file accepts a file it cannot parse, silently

parse_env_file expects KEY=Value lines and skips everything else. Given a
JSON file it parses zero variables and returns an empty dict, and deploy
carries on as if no --env-file had been passed:

[{"key": "CLOUDFLARE_API_TOKEN", "value": "..."}]

Deploy prints nothing unusual. The VM boots, the app starts, and the failure
finally surfaces inside the container as

Error: CLOUDFLARE_API_TOKEN environment variable is required

which reads like an application bug. [{"key": …, "value": …}] is a reasonable
guess at the format, and it happens to be the shape deploy builds internally
before encrypting.

Rejecting a file that yields no variables would be enough — an --env-file that
sets nothing is never intentional.

2. compose cannot set allowed_envs

An encrypted variable is only injected if app_compose.allowed_envs names it,
but vmm-cli compose has no flag for that list, so it always writes
"allowed_envs": []. The only way to set it is to edit the generated JSON by
hand.

That is worse than it sounds, because the app id is derived from that file. So
adding a variable name changes the app id, which invalidates anything already
keyed to it — for a dstack-gateway app that means the
_dstack-app-address.<domain> TXT record has to be updated before traffic works
again.

The symptom is identical to #1 (… environment variable is required), so from
the container's point of view "wrong file format" and "variable not allowed" are
indistinguishable.

Something like compose --allowed-env NAME (repeatable), or defaulting the list
to the keys of --env-file when one is given, would remove the hand edit and the
app-id churn that follows it.

3. deploy --kms-url sets two different things at once

It is used both for the host-side call that fetches the app's env encryption key
and for params["kms_urls"], which is what the guest is configured to talk to.
Those are rarely the same address.

In a local lab the KMS listens on 127.0.0.1:13501 on the host, while the guest
reaches it via QEMU user networking as kms.1022.dstack.org → 10.0.2.2. The
vmm config already has both:

kms_url  = "https://localhost:13501"              # host side
kms_urls = ["https://kms.1022.dstack.org:13501"]  # guest side

Passing --kms-url https://localhost:13501 — the only value that works for the
encryption step — overwrites the guest's list too, and the CVM then reboot-loops:

dstack-prepare.sh[334]: Error: Failed to request app keys
  0: Failed to get app keys from KMS
  1: Failed to get temp ca cert
  ...
  6: Connection refused (os error 111)
[FAILED] Failed to start dstack-prepare.service

No message connects that to the flag; the VM simply cycles between booting and
requesting app keys until you read the console log.

The workaround is to deploy without --env-file, then

vmm-cli.py update-env <vm> --env-file env --kms-url https://localhost:13501

and restart, because update_vm_env uses the URL only to fetch the key and does
not write it into the VM config. It works, but it means the documented one-step
path is the broken one.

A separate flag for the encryption endpoint — or falling back to the vmm's own
kms_url when only the guest list should change — would fix it. Erroring when
the given URL is a loopback address would at least fail at the right moment.

Environment

vmm-cli.py from main, local lab (vmm + kms + gateway on one TDX host),
guest image dstack-0.6.0.

主要言語
Rust
スター
555
フォーク
97
平均マージ
1日 3時間
マージ済み PR（30日）
199

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Dstack-TEE/dstack のほかの issue

Dstack-TEE/dstack の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。