sync: Release candidate v0.42.0

[vikramdevtron]

Description

Fixes #

Checklist:

• The title of the PR states what changed and the related issues number (used for the release note).
• Does this PR requires documentation updates?
• I've updated documentation as required by this PR.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have tested it for all user roles.
• I have added all the required unit/api test cases.

Does this PR introduce a user-facing change?

[bito-code-review]

Bito Automatic Review Skipped - Large PR

Bito didn't auto-review this change because the pull request exceeded the line limit. No action is needed if you didn't intend for the agent to review it. Otherwise, to manually trigger a review, type /review in a comment and save.

[sonarqubecloud]

Quality Gate failed

Failed conditions
4.1% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

To prevent incorrect values from being passed via this conversion, add explicit upper and lower bounds checks on the parsed integer value before converting from int (from strconv.Atoi) to int32. This should be done in the handler (in FetchRoleGroupById) before the call to int32(id). If the value does not fit in the acceptable range (0 <= id <= math.MaxInt32), return a validation error to the user. You'll need to import the math package to get the value of math.MaxInt32. This minimal check ensures conversion is always sound and prevents both negative and oversized values.

---

To fix the problem, any untrusted strings interpolated within quoted delimiters (e.g., '...') should be properly escaped so that embedded quote or backslash characters do not break out of the quotes. For Go code, the best practice is to escape single quotes as \' and backslashes as \\ before interpolation. This can be achieved using strings.ReplaceAll.
Specifically, in internal/util/ResourceErrorFactory.go, update all error message constructions that interpolate untrusted user input inside single quotes (e.g., lines 37, 47, 57, 67, 77). Add a helper function escapeSingleQuotes(s string), which will first escape \ and then escape '. Use this escaping only on those interpolated fields (such as resourceId, resourceName, fieldName, etc.) that appear inside quoted contexts.
You will need to import "strings" at the top of the file.

---

General approach:
Ensure that values interpolated inside quoted substrings are safely escaped so that embedded single quotes or escape characters cannot break out of the quote context.

Detailed solution:

• On all fmt.Sprintf calls wrapping possibly-untrusted data in '...' (i.e., where a string is interpolated between single quotes in a format string), first escape all backslashes (\ → \\) and single quotes (' → \') in the tainted variable before string interpolation.
• Use strings.ReplaceAll to escape backslashes before single quotes, to ensure escape characters aren't themselves broken.
• Ensure the proper import of the strings package in any file where the escaping is added.
• Only modify the variables which can actually receive untrusted user data (in this case, resourceName, resourceId, fieldName, and any other identifier wrapped inside '...' in a fmt.Sprintf).
• Do not over-escape where not needed (e.g. do not escape variables not wrapped in quotes).
• Only change the affected code region in the snippets provided; do NOT modify any other files or logic.

---

To fix the problem, we need to ensure that all user-supplied input used in constructing file paths (here: AppName and EnvName, which flow into gitOpsChartLocation → dir → chartYamlPath) is properly validated to prevent path traversal and other filesystem attacks.

Best approach:

• Explicitly validate that both AppName and EnvName (from pushChartToGitRequest) do not contain /, \, or .. sequences before using them in the path construction.
• If the inputs are only supposed to be a single path component (a typical assumption for names), reject any containing /, \, or ...
• Insert this validation at the top of the shouldMigrateProxyChartDependencies function in InstalledAppGitOpsService.go, before constructing any paths.
• On invalid input, log the possible attack and return an error. No further processing should occur in that case.

Implementation steps:

• Add validation checks (using e.g. strings.Contains) at the start of the function for pushChartToGitRequest.AppName and pushChartToGitRequest.EnvName.
• If invalid, log and return.
• No new dependencies are required, as strings is already imported.

---

General fix:
The problem is uncontrolled user input (AppName and EnvName from the API) being used to construct paths, potentially allowing path traversal or access outside the intended subdirectory. The best practice is to "sanitize" or validate these values before use:

• If these are supposed to be simple names, reject any value containing path separators (/, \) or parent directory references (..).
• If you need to support sub-paths, after constructing the full file path, ensure the result is still under the intended root directory using normalization and prefix checking.

Best fix for this case:

• Validate both AppName and EnvName fields in shouldMigrateProxyChartDependencies (and any code paths writing them as path components) to ensure they do not contain /, \, or ...
• If validation fails, log an error and fail the operation.
• This localizes the fix and does not change the interface (API), but immediately prevents the exploitation at the site of path construction.

What is needed:

• Add a validation snippet before constructing gitOpsChartLocation in shouldMigrateProxyChartDependencies.
• If pushChartToGitRequest.AppName or pushChartToGitRequest.EnvName are "unsafe", return an error before continuing.
• (If additional context is needed, a helper validation function can be defined in the same file for clarity and reuse.)

---

To fix this issue, we should ensure that any path components that originate from user input (directly or transitively) used to create directories or files are validated for safety. This includes repo names, app names, and chart locations. The single best way is to enforce, before using them in path construction:

1. No slashes (/, \), no .. sequences, and no leading/trailing whitespace.
2. Optionally, enforce an allow-list or pattern for acceptable values (e.g., only alphanumerics, hyphens, underscores).
3. The normalization of the final target directory should guarantee containment within the application's working directory.

For the shown snippets, edit the place where repo directory names and chart directory names are constructed (e.g., in PushChartToGitRepo, wherever gitOpsRepoName, chartLocation, chartDir, etc. are received, concatenate, and used for paths). Add validation checks and short-circuit/error out if they fail. It's best to create a helper validation function and call it at each relevant point.

Required edits:

• Implement a helper function isSafePathComponent(string) bool somewhere appropriate (e.g., top of pkg/deployment/gitOps/git/GitOperationService.go).
• In PushChartToGitRepo, before using gitOpsRepoName, chartLocation, and any other user-derived path in file/directory creation (especially before constructing chartDir and dir), call the helper and abort (return error/log) on failure.

---

To address the vulnerability, we must ensure that user-controlled input (AppName and EnvironmentName, used to construct gitOpsChartLocation) cannot contain directory traversal sequences, absolute paths, or path separators. This can be done by validating these fields in the service layer where the chart location is constructed, specifically before using them in filesystem operations.

The simplest and safest approach is to check each component for any path separator (/, \) or "..", and reject the request if such values are present. Since the inputs are expected to be identifiers (names), this restriction is reasonable and will prevent traversal and arbitrary directory creation.

The fix should be implemented at the start of PushChartToGitOpsRepoForHelmApp in pkg/deployment/gitOps/git/GitOperationService.go, before constructing gitOpsChartLocation. If an invalid input is detected, we should return an error and log the incident.

Required changes:

• Add validation in PushChartToGitOpsRepoForHelmApp for pushChartToGitRequest.AppName and pushChartToGitRequest.EnvName.
• Reject any value containing /, \, or "..".
• Log and return an error if invalid input is detected.

No new external dependency is required -- standard library strings suffices.

---

The best way to fix this problem is to exclude sensitive headers from being logged as part of the constructed curl command. Instead of logging all headers verbatim, the buildCurlCommand function should redact (<REDACTED>) or omit values for known sensitive headers, such as Authorization, Cookie, and any custom headers that commonly contain secrets. This can be achieved by maintaining a set of sensitive header names and replacing their values before including them in the logged curl command.

Specifically, within buildCurlCommand:

• Define a map or list of sensitive header names: e.g., "Authorization", "Cookie", "Set-Cookie", "X-Api-Key", etc.
• When constructing each header line, check if the header is sensitive.
• If sensitive, replace the value with <REDACTED>; otherwise, include the real value.
• The fix should only touch the buildCurlCommand function in the current file.

No new dependencies are needed: this logic can be expressed in a few lines of Go within the existing code.