Comments carry the mechanism, not the rationale; every argument removed
here is in the design proposal or the PR. Where one claim appeared at
several sites, the copy at the site that constrains the code stays.
Assisted-by: LLM
Signed-off-by: Timofei Larkin <lllamnyp@gmail.com>
CodeQL flags the SHA-1 and SHA-256 of a password as weak hashing of
sensitive data. Both are the forms the engines store and check against
and accept in no other form, and the design relies on the 32-character
random password rather than on the digest for strength, so the alerts
are dismissed with that reason and the code says it where the hashing
happens.
Assisted-by: LLM
Signed-off-by: Timofei Larkin <lllamnyp@gmail.com>
Cozystack generates managed application passwords at Helm render time
and keeps them in a Secret tenants can read again at any time, which a
deployment whose policy requires a credential shown once cannot accept.
The accepted design moves generation into the API: an
ApplicationDefinition declares its accounts and the stored form of a
password in a credentials block, and each account gets a
core.cozystack.io Credential whose mint and revoke subresources take a
TokenRequest-shaped CredentialRequest.
This adds the types, the built-in password formats, which the migration
CLI shares so a converted release and a mint store the same form, and
the account helpers that name the Secrets and read their record.
Design: https://github.com/cozystack/community/blob/main/design-proposals/user-secrets-api/README.md
Assisted-by: LLM
Signed-off-by: Timofei Larkin <lllamnyp@gmail.com>
Timofei Larkin