Severity: Info

Location: src/Servy.Service/Helpers/EnvironmentVariableHelper.cs:65-66

Code:

// Safety caps to prevent unbounded growth from complex recursive nesting
private const int MaxExpansionPasses = 5;
private const int MaxStringLength = 32768;

Explanation:
These two caps protect the environment-variable expansion pipeline from pathological inputs (circular references, exponential growth). Other application-wide caps of the same nature live in AppConfig — MaxServiceNameLength, MaxDisplayNameLength, MaxDescriptionLength, MaxArgumentLength, InputRegexTimeoutMs. Keeping these two in a private const inside EnvironmentVariableHelper makes them:

• Invisible to anyone reviewing application limits in AppConfig
• Impossible to reuse from a unit test that wants to verify the truncation boundary
• Impossible to tune per environment (e.g., a deployment with a known need for longer expanded values)

MaxStringLength = 32768 in particular happens to match the Win32 CreateProcess argument limit (AppConfig.MaxArgumentLength = 32000 + headroom), and the relationship between these two numbers is load-bearing for security: if the env expansion cap were ever raised above the command-line cap, the downstream code would silently truncate differently. Centralizing both makes that relationship explicit.

Suggested fix:
Move to AppConfig:

public const int MaxEnvVarExpansionPasses = 5;
public const int MaxEnvVarExpandedLength = 32768;

Then reference from EnvironmentVariableHelper:

while (changed && pass < AppConfig.MaxEnvVarExpansionPasses);
...
if (expanded != null && expanded.Length > AppConfig.MaxEnvVarExpandedLength)

Add an XML doc comment on MaxEnvVarExpandedLength noting the relationship with MaxArgumentLength so future tuning doesn't break that invariant.