CI-sichere Release-Signing-Konfiguration für app und humanoperator

[Android-PowerUser]

Motivation

• CI-Builds brauchen eine sichere, nicht im Repo gespeicherte Signing-Konfiguration, die über Umgebungsvariablen gesetzt wird.
• Die Build-Skripte sollen bei fehlenden Release-Secrets klar fehlschlagen, statt still geheimniskrämerisch unsignierte Artefakte zu erzeugen.
• google-services.json soll unverändert versioniert bleiben und nicht Teil der Signing-Logik werden.

Description

• In app/build.gradle.kts werden die Variablen ANDROID_KEYSTORE_PATH, ANDROID_KEY_ALIAS, ANDROID_KEYSTORE_PASSWORD und ANDROID_KEY_PASSWORD aus System.getenv gelesen und in einer signingConfigs { create("release") { ... } } verwendet.
• buildTypes.release ist in app und humanoperator explizit mit signingConfig = signingConfigs.getByName("release") verknüpft und Nicht-Release-Builds bleiben unverändert.
• Guard-Logik prüft, ob ein Release-Task angefordert wurde (gradle.startParameter.taskNames) und löst bei fehlenden Variablen ein klares error(...) mit den fehlenden Variablen aus.
• Analoges Setup wurde in humanoperator/build.gradle.kts ergänzt und eine kurze Dokumentation docs/ci-signing.md angelegt; README.md wurde um einen Link zur CI-Dokumentation ergänzt.

Testing

• ./gradlew :app:help :humanoperator:help wurde erfolgreich ausgeführt und bestätigt, dass die Gradle-Skripte syntaktisch auswertbar sind.
• ./gradlew :app:assembleRelease --dry-run und ./gradlew :humanoperator:assembleRelease --dry-run wurden ausgeführt und liefern die erwartete, klare Guard-Fehlermeldung, wenn die Signing-Umgebungsvariablen nicht gesetzt sind.
• ./gradlew :app:lintDebug :humanoperator:lintDebug wurde versucht; Lint schlug fehl wegen einer bestehenden Kotlin-Metadata-Inkompatibilität in einer Abhängigkeit, die unabhängig von diesen Signing-Änderungen ist.

---

Codex Task

[amazon-q-developer]

Review Summary

This PR implements CI-friendly release signing configuration for the app and humanoperator modules. The approach of using environment variables for signing credentials is sound, but critical issues must be addressed before merge:

Critical Issues (Must Fix)

1. Logic Error in both modules: Release build types unconditionally reference signing configs that may be uninitialized when environment variables are missing. The current guard logic doesn't protect against all build invocation scenarios (IDE builds, indirect task invocations), which could produce unsigned APKs without clear errors.

2. Security Vulnerability in both modules: Path traversal risk in keystore path handling - the file() function accepts unvalidated paths from environment variables, enabling potential unauthorized file access on build systems.

Recommendation

Address the signing config conditional assignment and add path validation before merge. These defects could compromise build integrity and security in CI environments.

---

You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.

[amazon-q-developer]

🛑 Security Vulnerability: Using file() with environment variable path enables path traversal attacks¹. An attacker controlling ANDROID_KEYSTORE_PATH could read arbitrary files from the build system (e.g., ../../../../etc/passwd). Validate the path resolves within expected directories or use absolute path validation before passing to file().

Footnotes

1. CWE-22: Path Traversal - https://cwe.mitre.org/data/definitions/22.html ↩

[amazon-q-developer]

🛑 Security Vulnerability: Using file() with environment variable path enables path traversal attacks¹. An attacker controlling ANDROID_KEYSTORE_PATH could read arbitrary files from the build system (e.g., ../../../../etc/passwd). Validate the path resolves within expected directories or use absolute path validation before passing to file().

Footnotes

1. CWE-22: Path Traversal - https://cwe.mitre.org/data/definitions/22.html ↩