Agents sometimes incidentally stumble upon the value of CYDO_AUTH_PASS when looking for unrelated environment variables. CyDo passes its full environment to every agent process it launches, so any agent (or tool the agent runs) that lists or greps the environment sees the web UI password, and it ends up in the agent's transcript and in CyDo's own history.
Two things would reduce this:
-
Don't pass the secret to subprocesses. After reading CYDO_AUTH_PASS (and CYDO_AUTH_USER) at startup, remove them from the process environment so agents and other children never inherit them.
-
Offer a way to set the value that avoids the environment entirely. Today the variable is the only supported mechanism (the alternatives are leaving it unset, which only works interactively, or setting it empty, which disables auth), so anyone running CyDo as a service keeps the password in plaintext in the unit file or an environment file. Options in the usual style: a CYDO_AUTH_PASS_FILE variable naming a file to read the password from, and/or support for systemd credentials, where the unit declares LoadCredential=cydo-auth-pass:/path/to/file and CyDo reads $CREDENTIALS_DIRECTORY/cydo-auth-pass. The systemd route also permits LoadCredentialEncrypted= for encryption at rest.
Item 1 alone closes the leak for existing setups; item 2 keeps the value out of the unit file and the process environment altogether.
Agents sometimes incidentally stumble upon the value of
CYDO_AUTH_PASSwhen looking for unrelated environment variables. CyDo passes its full environment to every agent process it launches, so any agent (or tool the agent runs) that lists or greps the environment sees the web UI password, and it ends up in the agent's transcript and in CyDo's own history.Two things would reduce this:
Don't pass the secret to subprocesses. After reading
CYDO_AUTH_PASS(andCYDO_AUTH_USER) at startup, remove them from the process environment so agents and other children never inherit them.Offer a way to set the value that avoids the environment entirely. Today the variable is the only supported mechanism (the alternatives are leaving it unset, which only works interactively, or setting it empty, which disables auth), so anyone running CyDo as a service keeps the password in plaintext in the unit file or an environment file. Options in the usual style: a
CYDO_AUTH_PASS_FILEvariable naming a file to read the password from, and/or support for systemd credentials, where the unit declaresLoadCredential=cydo-auth-pass:/path/to/fileand CyDo reads$CREDENTIALS_DIRECTORY/cydo-auth-pass. The systemd route also permitsLoadCredentialEncrypted=for encryption at rest.Item 1 alone closes the leak for existing setups; item 2 keeps the value out of the unit file and the process environment altogether.