Issue Description
After migrating the configuration, environment variables utilizing the %{env:VAR}% syntax are no longer expanded by the parser and are instead interpreted literally.
Expected Behavior
Environment variable placeholders fail to resolve and remain as literal strings within the active configuration.
Stalwart Version
v0.16.x
Installation Method
Docker
Database Backend
PostgreSQL
Blob Storage
S3-compatible
Search Engine
PostgreSQL
Directory Backend
LDAP
Additional Context
Additional Context
An example of this configuration can be observed in the S3 bucket access key referenced from a secret:
Repository: arch-anes/self-hosted-services
File: self-hosted-services/charts/services/templates/stalwart.yaml
Commit: 6ee31ce22135d40900f34b028e418c3cb2625354
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
on
The %{env:VAR}% form was a macro of the pre-0.16 static TOML configuration; the 0.16 configuration lives in the database and doesn’t interpret that macro, so after migrating it’s kept as a literal string. That’s expected rather than a parser regression.
For an S3 access key or secret sourced from the environment, use the typed secret instead of the macro: set the field to an object with “@type”:“EnvironmentVariable” and a “variableName”, which resolves std::env at runtime. That’s the supported way to reference an env var in the current config model.
You’re right that there’s a documentation gap here and I’ll get that added.
I have tried the following self-hosted-services/charts/services/templates/stalwart.yaml at b2455d0ad79c2e4acc18dddb637308a1a6418190 · arch-anes/self-hosted-services · GitHub but got this error:
error: BlobStore: update failed for id singleton: error: invalidPatch | Invalid value for property. | Properties: accessKey
Is that reproducible with version 0.16.15 ?
Tested in v0.16.14 I believe. I don’t think anything regarding SecretKeyOptional changed in v0.16.15 to warrant a retry.
The accessKey was a string key which it did not accept environment variables. It was now converted to an enum which accepts environment variable names as well as file paths. The fix will be included v0.16.16.
Thanks for the quick patch @stalwart! Would it be possible to do something similar for MtaRouteRelay.authUsername and MtaRouteRelay.addressas well?
I could also submit a PR if you’d like.
It is technically possible but we want to avoid having enums for every single property (others might have similar ideas too). I recommend using the CLI or JMAP API to programmatically update the fields you need.