Release v2.3.0: ARM64 support + configurable SSL enforcement

[aaronlippold]

Summary

This release adds ARM64/Apple Silicon support and makes SSL enforcement configurable for flexible Kubernetes deployments.

Changes

Multi-Platform Docker Builds

• Enable ARM64 builds in GitHub Actions workflow
• Uncomment platforms: linux/amd64,linux/arm64 in push-to-docker.yml
• Enables deployment on Apple Silicon Macs and ARM-based cloud instances

Configurable SSL Enforcement

• Add FORCE_SSL environment variable support
• Make config.force_ssl respect FORCE_SSL setting
• Make config.assume_ssl respect FORCE_SSL setting (DRY approach)
• Update all documentation with FORCE_SSL usage examples

Use Cases

Local/Development Kubernetes:

FORCE_SSL=false

• Allows HTTP access without SSL redirects
• Suitable for Kind, Minikube, development clusters
• Works with Helm charts that don't configure ingress TLS

Production (with Ingress + TLS):

FORCE_SSL=true  # Default

• Enforces HTTPS, secure cookies, HSTS headers
• Ingress handles SSL termination
• Standard production deployment pattern

Testing

• Built and tested locally with ARM64 and AMD64 platforms
• Verified FORCE_SSL=false allows HTTP operation
• Verified FORCE_SSL=true maintains production security
• Deployed successfully to Kind cluster with Helm chart

Compatibility

• Backward compatible (defaults to true, existing behavior)
• No breaking changes
• Works with existing deployment methods

Documentation Updated

• ENVIRONMENT_VARIABLES.md
• .env.production.example
• docs/getting-started/environment-variables.md

Authored by: Aaron Lippoldlippold@gmail.com

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

To fix this, explicitly define minimal GITHUB_TOKEN permissions for jobs that only need to read repository contents. The validate and test jobs simply check out code, run Ruby/Node setup, and execute tests and static analysis; they do not write to GitHub or modify releases. Therefore, adding permissions: contents: read to these jobs is the least-privilege fix that preserves all existing behavior.

Concretely:

• In .github/workflows/release.yml, under jobs.validate (just below runs-on: ubuntu-24.04), add:

  permissions:
    contents: read

• In the same file, under jobs.test (just below needs: validate), add:

  permissions:
    contents: read

No other changes, imports, or new definitions are required. The publish-release job already has permissions: contents: write and should be left as-is.

To fix the problem, add an explicit permissions block to the test job that grants only the minimal required scope. Since test just checks out the repository and runs tests, contents: read is sufficient. This prevents the job from inheriting potentially broader default token permissions while preserving all current functionality.

Concretely:

• Edit .github/workflows/release.yml.
• Under the test job (the one with name: Run Test Suite on line 75), insert:

    permissions:
      contents: read

between runs-on: ubuntu-24.04 and needs: validate. No other jobs need changes: create-draft-release already has permissions: contents: write, and validate does not appear to require write access (you could optionally also add contents: read there, but CodeQL’s reported issue is about the test job, so we’ll focus on that). No imports or external dependencies are required for this change.

To fix the problem, explicitly restrict the GITHUB_TOKEN permissions for the build-docker job by adding a permissions block that grants only read access to repository contents. This ensures the job does not inherit potentially broader repository defaults (such as contents: write), satisfying the least-privilege recommendation and the CodeQL rule.

Concretely, in .github/workflows/release.yml, within the build-docker job definition (lines around 190–195), add:

permissions:
  contents: read

just under needs: [validate, test, create-draft-release] (or directly under runs-on:—order among job-level keys does not matter in YAML). No additional imports or methods are required, and no changes are needed to any steps in the job. This will keep existing functionality intact because the job only needs to check out code and read README.md, which are compatible with contents: read.

In general, the safest way to fix SQL injection risks in Rails is to avoid manually constructing SQL strings and instead rely on ActiveRecord’s parameterization mechanisms: hashes, arrays with placeholders, or AREL predicates. We should ensure that user-supplied data is only ever used as bound parameters, and never interpolated directly into the query string.

In this case, the primary concern is build_ilike_conditions, which returns a ["sql with ? placeholders", *values] array that is splatted into where. Although the values are safe, the pattern of manually building SQL strings is what triggers the CodeQL alert. The best fix without changing functionality is to refactor build_ilike_conditions so that it no longer returns a raw SQL string, but instead constructs an Arel::Nodes::Node condition tree; we can then pass that node directly to where, which is fully parameterized by Rails/AREL. We keep the existing behavior—OR-ing across both terms and columns, and using %term% ILIKE matching—while letting AREL handle bindings.

Concretely, in app/controllers/api/search_controller.rb, we will:

• Replace the current build_ilike_conditions implementation with one that:
  • Returns an Arel::Nodes::Node instead of [sql, *values].
  • Uses arel_table[col].matches("%#{term}%", nil, true) (or matches with Arel::Nodes::NamedFunction.new('LOWER', ...) if needed), combined with .or across columns and terms.
• Update the two call sites:
  • current_user.available_projects.where(*build_ilike_conditions(%w[name description])) → ...where(build_ilike_conditions(Project, %w[name description]))
  • Component.where(project_id: project_ids).where(*build_ilike_conditions(%w[name prefix])) → ...where(build_ilike_conditions(Component, %w[name prefix]))
• Change the build_ilike_conditions method signature to accept the model class, e.g. def build_ilike_conditions(model_class, columns) and use model_class.arel_table to build column references.

No new imports are needed; AREL is available as part of ActiveRecord. Functionality will remain the same: it still performs an OR across all columns and all search terms, but in a way that is clearly parameterized and friendlier to static analysis.

---

[gitguardian]

⚠️ GitGuardian has uncovered 4 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
25086139	Triggered	Generic Password	5d5ca50	app/javascript/components/auth/tests/PasswordInput.spec.ts	View secret
23525922	Triggered	Generic Password	e32a867	cli/cmd/setup_test.go	View secret
23525923	Triggered	Generic Password	f5ac2e3	app/javascript/composables/tests/useProfile.spec.ts	View secret
23525924	Triggered	Generic Password	bb0a44e	docker-compose.dev.yml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[sonarqubecloud]

Quality Gate failed

Failed conditions
100 Security Hotspots
3.3% Duplication on New Code (required ≤ 3%)
C Security Rating on New Code (required ≥ A)
E Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE