mindersec/minder

Describe the issue Summary The gitlab/license entity property (RepoPropertyLicense) is always empty for GitLab repositories because the project fetch in internal/providers/gitlab/repository_properties.go does not pass the ?license=true query parameter required by the GitLab API to include license information in the response. Reproduction Without ?license=true: GET /api/v4/projects/gitlab-org%2Fgitlab → "license": null With ?license=true: GET /api/v4/projects/gitlab-org%2Fgitlab?license=true → "license": {"key": "mit", "name": "MIT License", ...} Fix In getGitLabProject(), append ?license=true to the project URL path: projectURLPath, err := url.JoinPath("projects", url.PathEscape(upstreamID)) // change to: projectURLPath = projectURLPath + "?license=true" Impact gitlab/license property is always "" for all GitLab repositories Any rule relying on RepoPropertyLicense or .Entity.License for GitLab will never get license data Discovered during OSPS level-1 rule porting work (#6435)

Describe the issue CLI JSON output generated via protojson is not stable across environments. Specifically, spacing differences (e.g., extra spaces after :) can vary between local runs and CI, even when the underlying data is identical. This causes golden tests that rely on exact JSON string matching to fail intermittently. To Reproduce Run CLI tests that include JSON golden output (e.g., artifact get) Compare outputs across different environments (local vs CI) Observe differences in spacing/formatting (extra spaces after :) Tests fail due to string mismatch despite identical data What version are you using? Latest main (after #6420 / #6417 changes)

Inspired by https://github.com/mindersec/minder/pull/6420/changes#r3150107180 We have a standard field ordering in https://github.com/mindersec/minder-rules-and-profiles for Profiles, RuleTypes, and DataSources. It's generally: version type name context (if needed/present) (other fields, generally descriptive / metadata before deep structure) It would be great if places where we print YAML could order the fields -- it's not clear how hard this is, but it might be a good first issue.

Please describe the enhancement Currently, the executor event handling timeout is hardcoded using DefaultExecutionTimeout. This makes it difficult to adjust execution behavior across different environments (e.g., local development vs CI vs production). Any change requires modifying code instead of using configuration. This could be improved by making the execution timeout configurable, allowing users to tune behavior without code changes. This would provide flexibility and better control over execution timing. Solution Proposal Introduce a configurable execution timeout in the server configuration: Add a new execution_timeout field to server config Pass this value through the service layer into the executor event handler Validate the value and fallback to DefaultExecutionTimeout if invalid (zero or negative) Log the effective timeout during initialization for visibility This ensures that timeout behavior is configurable while maintaining safe defaults. Describe alternatives you've co

Please describe the enhancement The REST datasource handler (internal/datasources/rest/handler.go) has several hardcoded values and unimplemented stubs that make it hard to use with real-world APIs: Timeout is hardcoded to 5s (line 160-161) : there's a TODO acknowledging this. Slower upstream APIs will just time out with no way to adjust. Auth is unimplemented (line 62): if your datasource points at an API that isn't the registered provider, there's no way to pass API keys or bearer tokens. Fallback is a no-op (lines 61, 228): the struct references it and doRequest() has a placeholder, but nothing actually happens when a request fails. 1MB response limit is hardcoded (line 40): MaxBytesLimit = 1 << 20 with no override. Some APIs legitimately return more. No custom HTTP client support** (line 158): another existing TODO. These are all flagged with TODO comments in the code already. Solution Proposal I think the cleanest approach would be adding a few optional fields to RestDataSource_