Add analyze mode and summary reporting to kInit

kleb commented

2025-12-31 03:47:42 +01:00

Owner

User description

Introduced analyze.sh for configuration verification and module result analysis.
Added --analyze option to kInit.sh to enable analysis mode.
Implemented summary reporting of module execution results.
Updated various scripts to conditionally remove variable files based on analyze mode.
Updated checksums for modified scripts.

PR Type

Enhancement, Other

Description

Introduced analyze.sh to verify system, utilities, and software configurations.
Added --analyze flag to kInit.sh for post-execution verification.
Implemented recordModuleResult to track and report module success/failure.
Modified module cleanup logic to preserve variable files when analysis mode is active.

Diagram Walkthrough

flowchart LR
  kInit["kInit.sh"] -- "--analyze" --> Analyze["analyze.sh"]
  Analyze -- "sources" --> Vars["*.vars files"]
  Analyze -- "verifies" --> System["System State"]
  kInit -- "tracks" --> Results["Module Results"]

File Walkthrough

Relevant files

Enhancement

7 files

analyze.sh `New script for post-installation configuration verification`	+205/-0
miscellaneous.sh `Conditional cleanup of variable files based on analyze mode`	+3/-1
software.sh `Preserve software variables when analysis is enabled`	+3/-1
system.sh `Prevent deletion of system variables in analyze mode`	+3/-1
utilities.sh `Skip utilities variable cleanup during analysis`	+3/-1
utils.sh `Added helper to record and track module execution results`	+10/-0
kInit.sh `Added --analyze CLI option and help documentation`	+160/-0

Configuration changes

1 files

checksums.sha256
Updated checksums for modified shell scripts +6/-5

### **User description** - Introduced `analyze.sh` for configuration verification and module result analysis. - Added `--analyze` option to `kInit.sh` to enable analysis mode. - Implemented summary reporting of module execution results. - Updated various scripts to conditionally remove variable files based on analyze mode. - Updated checksums for modified scripts. ___ ### **PR Type** Enhancement, Other ___ ### **Description** - Introduced `analyze.sh` to verify system, utilities, and software configurations. - Added `--analyze` flag to `kInit.sh` for post-execution verification. - Implemented `recordModuleResult` to track and report module success/failure. - Modified module cleanup logic to preserve variable files when analysis mode is active. ___ ### Diagram Walkthrough ```mermaid flowchart LR kInit["kInit.sh"] -- "--analyze" --> Analyze["analyze.sh"] Analyze -- "sources" --> Vars["*.vars files"] Analyze -- "verifies" --> System["System State"] kInit -- "tracks" --> Results["Module Results"] ``` <details> <summary><h3> File Walkthrough</h3></summary> <table><thead><tr><th></th><th align="left">Relevant files</th></tr></thead><tbody><tr><td><strong>Enhancement</strong></td><td><details><summary>7 files</summary><table> <tr> <td><strong>analyze.sh</strong><dd><code>New script for post-installation configuration verification</code></dd></td> <td><a href="https://git.kleb.sh/kleb/kInit/src/branch/feature/analyse/installer/analyze.sh">+205/-0</a>  </td> </tr> <tr> <td><strong>miscellaneous.sh</strong><dd><code>Conditional cleanup of variable files based on analyze mode</code></dd></td> <td><a href="https://git.kleb.sh/kleb/kInit/src/branch/feature/analyse/installer/miscellaneous/miscellaneous.sh">+3/-1</a>      </td> </tr> <tr> <td><strong>software.sh</strong><dd><code>Preserve software variables when analysis is enabled</code>          </dd></td> <td><a href="https://git.kleb.sh/kleb/kInit/src/branch/feature/analyse/installer/software/software.sh">+3/-1</a>      </td> </tr> <tr> <td><strong>system.sh</strong><dd><code>Prevent deletion of system variables in analyze mode</code>          </dd></td> <td><a href="https://git.kleb.sh/kleb/kInit/src/branch/feature/analyse/installer/system/system.sh">+3/-1</a>      </td> </tr> <tr> <td><strong>utilities.sh</strong><dd><code>Skip utilities variable cleanup during analysis</code>                    </dd></td> <td><a href="https://git.kleb.sh/kleb/kInit/src/branch/feature/analyse/installer/utilities/utilities.sh">+3/-1</a>      </td> </tr> <tr> <td><strong>utils.sh</strong><dd><code>Added helper to record and track module execution results</code></dd></td> <td><a href="https://git.kleb.sh/kleb/kInit/src/branch/feature/analyse/installer/utils.sh">+10/-0</a>    </td> </tr> <tr> <td><strong>kInit.sh</strong><dd><code>Added --analyze CLI option and help documentation</code>                </dd></td> <td><a href="https://git.kleb.sh/kleb/kInit/src/branch/feature/analyse/kInit.sh">+160/-0</a>  </td> </tr> </table></details></td></tr><tr><td><strong>Configuration changes</strong></td><td><details><summary>1 files</summary><table> <tr> <td><strong>checksums.sha256</strong><dd><code>Updated checksums for modified shell scripts</code>                          </dd></td> <td><a href="https://git.kleb.sh/kleb/kInit/src/branch/feature/analyse/checksums.sha256">+6/-5</a>      </td> </tr> </table></details></td></tr></tr></tbody></table> </details> ___

kleb added 1 commit

2025-12-31 03:47:42 +01:00

Add analyze mode and summary reporting to kInit db1c352586

- Introduced `analyze.sh` for configuration verification and module result analysis.
- Added `--analyze` option to `kInit.sh` to enable analysis mode.
- Implemented summary reporting of module execution results.
- Updated various scripts to conditionally remove variable files based on analyze mode.
- Updated checksums for modified scripts.

kAgent commented

2025-12-31 03:48:03 +01:00

Collaborator

PR Reviewer Guide 🔍

(Review updated until commit `e46f30afe0`)

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 Security concerns

Arbitrary Code Execution:
The analyze.sh script sources multiple .vars files (lines 32, 198, 242). Since these files are part of the installer's state, if an attacker can modify these files on the filesystem or intercept them during download, they can execute arbitrary bash commands with the privileges of the user running kInit.sh (likely root). Consider using a safer parsing method like grep or awk to extract specific values instead of sourcing the entire file.

⚡ Recommended focus areas for review

Shell Injection

The script uses source on .vars files (e.g., system.vars, utilities.vars) which are likely generated or downloaded. If these files are compromised or contain untrusted input, it leads to arbitrary code execution.

source "system.vars"

Logic Error

In verifySystemConfig, the check for SWAP_SIZE uses -eq on a variable that might be an empty string or non-numeric if the .vars file is malformed, which will cause a shell script error.

if [[ "$SWAP_SIZE" -eq 0 ]]; then

Missing Validation

The runAnalysis function accepts a string $1 and uses grep to check for success. If the input string is not formatted exactly as expected (e.g., extra spaces or different casing), the verification blocks for specific modules will be silently skipped.

if [[ -f "system.vars" ]] && echo "$moduleResults" | grep -q "System=success"; then
    verifySystemConfig
fi

if [[ -f "utilities.vars" ]] && echo "$moduleResults" | grep -q "Utilities=success"; then
    verifyUtilitiesConfig
fi

if [[ -f "software.vars" ]] && echo "$moduleResults" | grep -q "Software=success"; then
    verifySoftwareConfig
fi

if [[ -f "miscellaneous.vars" ]] && echo "$moduleResults" | grep -q "Miscellaneous=success"; then
    verifyMiscellaneousConfig
fi

## PR Reviewer Guide 🔍 #### (Review updated until commit https://git.kleb.sh/kleb/kInit/commit/e46f30afe00afd6a23e9bb3ce645ce4e678a2191) Here are some key observations to aid the review process: <table> <tr><td>⏱️ <strong>Estimated effort to review</strong>: 2 🔵🔵⚪⚪⚪</td></tr> <tr><td>🧪 <strong>No relevant tests</strong></td></tr> <tr><td>🔒 <strong>Security concerns</strong><br><br> <strong>Arbitrary Code Execution:</strong><br> The `analyze.sh` script sources multiple `.vars` files (lines 32, 198, 242). Since these files are part of the installer's state, if an attacker can modify these files on the filesystem or intercept them during download, they can execute arbitrary bash commands with the privileges of the user running `kInit.sh` (likely root). Consider using a safer parsing method like `grep` or `awk` to extract specific values instead of sourcing the entire file.</td></tr> <tr><td>⚡ <strong>Recommended focus areas for review</strong><br><br> <details><summary><a href='https://git.kleb.sh/kleb/kInit/src/branch/feature/analyse/installer/analyze.sh#L32-L32'><strong>Shell Injection</strong></a> The script uses `source` on `.vars` files (e.g., `system.vars`, `utilities.vars`) which are likely generated or downloaded. If these files are compromised or contain untrusted input, it leads to arbitrary code execution. </summary> ```shell source "system.vars" ``` </details> <details><summary><a href='https://git.kleb.sh/kleb/kInit/src/branch/feature/analyse/installer/analyze.sh#L58-L58'><strong>Logic Error</strong></a> In `verifySystemConfig`, the check for `SWAP_SIZE` uses `-eq` on a variable that might be an empty string or non-numeric if the `.vars` file is malformed, which will cause a shell script error. </summary> ```shell if [[ "$SWAP_SIZE" -eq 0 ]]; then ``` </details> <details><summary><a href='https://git.kleb.sh/kleb/kInit/src/branch/feature/analyse/installer/analyze.sh#L358-L372'><strong>Missing Validation</strong></a> The `runAnalysis` function accepts a string `$1` and uses `grep` to check for success. If the input string is not formatted exactly as expected (e.g., extra spaces or different casing), the verification blocks for specific modules will be silently skipped. </summary> ```shell if [[ -f "system.vars" ]] && echo "$moduleResults" | grep -q "System=success"; then verifySystemConfig fi if [[ -f "utilities.vars" ]] && echo "$moduleResults" | grep -q "Utilities=success"; then verifyUtilitiesConfig fi if [[ -f "software.vars" ]] && echo "$moduleResults" | grep -q "Software=success"; then verifySoftwareConfig fi if [[ -f "miscellaneous.vars" ]] && echo "$moduleResults" | grep -q "Miscellaneous=success"; then verifyMiscellaneousConfig fi ``` </details> </td></tr> </table>

kAgent commented

2025-12-31 03:48:22 +01:00

Collaborator

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Prevent variable collisions by isolating module sourcing The script sources multiple `.vars` files into the same shell environment without namespacing. This can lead to variable collisions where a later file overwrites values from an earlier one, causing incorrect verification results. Consider using a subshell or clearing specific variables between module checks. installer/analyze.sh [21-128] `-source "system.vars" -... -source "utilities.vars" -... -source "software.vars" +( + source "system.vars" + # ... verification logic ... +) +( + source "utilities.vars" + # ... verification logic ... +)` Suggestion importance[1-10]: 7 __ Why: The script sources multiple `.vars` files into the global scope. Since these files likely share common variable names (like `TRUE`, `FALSE`, or module-specific flags), sourcing them sequentially in the same shell can lead to unexpected behavior or false positives/negatives in verification.	Medium
General	Check the correct user's shell during verification The script hardcodes a check against the `root` user in `/etc/passwd`. If the installer was run for a non-root user, this verification will incorrectly report a failure even if the current user's shell was successfully changed. Use the `$USER` variable or `getent passwd $(whoami)` to check the shell of the user who actually performed the installation. installer/analyze.sh [45-47] `if [[ "${FISH_DEFAULT_SHELL:-}" == "TRUE" ]]; then - fishShell=$(grep "^root:" /etc/passwd \| cut -d: -f7) - if [[ "$fishShell" == "fish" ]]; then + current_user=$(whoami) + userShell=$(getent passwd "$current_user" \| cut -d: -f7) + if [[ "$userShell" == "fish" ]]; then` Suggestion importance[1-10]: 5 __ Why: Hardcoding the check for the `root` user's shell is restrictive. While many installers run as root, the verification should ideally target the user for whom the environment was configured, or at least use a more dynamic approach than `grep "^root:"`.	Low
Possible issue	Verify specific SSH keys instead of file existence The check for SSH configuration only verifies the existence of the `authorized_keys` file but does not check if the keys defined in `SSH_KEY_DCS` are actually present inside that file. This can lead to false positives if the file exists but is empty or contains unrelated keys. Use `grep` to verify the presence of at least one expected key. installer/analyze.sh [66-74] if [[ -v SSH_KEY_DCS && ${#SSH_KEY_DCS[@]} -gt 0 ]]; then + local key_found=0 if [[ -f "$HOME/.ssh/authorized_keys" ]]; then + for key in "${SSH_KEY_DCS[@]}"; do + if grep -q "$key" "$HOME/.ssh/authorized_keys"; then + key_found=1; break + fi + done + fi + if [[ $key_found -eq 1 ]]; then + printf " ${colors[GREEN]}[+]${colors[RESET]} SSH authorized_keys configured\n" + ((verified++)) + else + printf " ${colors[RED]}[x]${colors[RESET]} SSH authorized_keys NOT configured correctly\n" + ((failed++)) + fi +fi Suggestion importance[1-10]: 6 __ Why: The current check only verifies that the `authorized_keys` file exists, which is a weak verification of whether the configuration was actually applied. Checking for the presence of the keys defined in `SSH_KEY_DCS` provides a much more accurate result.	Low

## PR Code Suggestions ✨  Explore these optional code suggestions: <table><thead><tr><td><strong>Category</strong></td><td align=left><strong>Suggestion                                                                                                                                    </strong></td><td align=center><strong>Impact</strong></td></tr><tbody><tr><td rowspan=2>General</td> <td> <details><summary>Prevent variable collisions by isolating module sourcing</summary> ___ **The script sources multiple <code>.vars</code> files into the same shell environment without <br>namespacing. This can lead to variable collisions where a later file overwrites <br>values from an earlier one, causing incorrect verification results. Consider using a <br>subshell or clearing specific variables between module checks.** [installer/analyze.sh [21-128]](https://git.kleb.sh/kleb/kInit/src/branch/feature/analyse/installer/analyze.sh#L21-L128) ```diff -source "system.vars" -... -source "utilities.vars" -... -source "software.vars" +( + source "system.vars" + # ... verification logic ... +) +( + source "utilities.vars" + # ... verification logic ... +) ``` <details><summary>Suggestion importance[1-10]: 7</summary> __ Why: The script sources multiple `.vars` files into the global scope. Since these files likely share common variable names (like `TRUE`, `FALSE`, or module-specific flags), sourcing them sequentially in the same shell can lead to unexpected behavior or false positives/negatives in verification. </details></details></td><td align=center>Medium </td></tr><tr><td> <details><summary>Check the correct user's shell during verification</summary> ___ **The script hardcodes a check against the <code>root</code> user in <code>/etc/passwd</code>. If the installer <br>was run for a non-root user, this verification will incorrectly report a failure <br>even if the current user's shell was successfully changed. Use the <code>$USER</code> variable or <br><code>getent passwd $(whoami)</code> to check the shell of the user who actually performed the <br>installation.** [installer/analyze.sh [45-47]](https://git.kleb.sh/kleb/kInit/src/branch/feature/analyse/installer/analyze.sh#L45-L47) ```diff if [[ "${FISH_DEFAULT_SHELL:-}" == "TRUE" ]]; then - fishShell=$(grep "^root:" /etc/passwd | cut -d: -f7) - if [[ "$fishShell" == *"fish"* ]]; then + current_user=$(whoami) + userShell=$(getent passwd "$current_user" | cut -d: -f7) + if [[ "$userShell" == *"fish"* ]]; then ``` <details><summary>Suggestion importance[1-10]: 5</summary> __ Why: Hardcoding the check for the `root` user's shell is restrictive. While many installers run as root, the verification should ideally target the user for whom the environment was configured, or at least use a more dynamic approach than `grep "^root:"`. </details></details></td><td align=center>Low </td></tr><tr><td rowspan=1>Possible issue</td> <td> <details><summary>Verify specific SSH keys instead of file existence</summary> ___ **The check for SSH configuration only verifies the existence of the <code>authorized_keys</code> <br>file but does not check if the keys defined in <code>SSH_KEY_DCS</code> are actually present <br>inside that file. This can lead to false positives if the file exists but is empty <br>or contains unrelated keys. Use <code>grep</code> to verify the presence of at least one expected <br>key.** [installer/analyze.sh [66-74]](https://git.kleb.sh/kleb/kInit/src/branch/feature/analyse/installer/analyze.sh#L66-L74) ```diff if [[ -v SSH_KEY_DCS && ${#SSH_KEY_DCS[@]} -gt 0 ]]; then + local key_found=0 if [[ -f "$HOME/.ssh/authorized_keys" ]]; then + for key in "${SSH_KEY_DCS[@]}"; do + if grep -q "$key" "$HOME/.ssh/authorized_keys"; then + key_found=1; break + fi + done + fi + if [[ $key_found -eq 1 ]]; then + printf " ${colors[GREEN]}[+]${colors[RESET]} SSH authorized_keys configured\n" + ((verified++)) + else + printf " ${colors[RED]}[x]${colors[RESET]} SSH authorized_keys NOT configured correctly\n" + ((failed++)) + fi +fi ``` <details><summary>Suggestion importance[1-10]: 6</summary> __ Why: The current check only verifies that the `authorized_keys` file exists, which is a weak verification of whether the configuration was actually applied. Checking for the presence of the keys defined in `SSH_KEY_DCS` provides a much more accurate result. </details></details></td><td align=center>Low </td></tr></tr></tbody></table>

kleb added 2 commits

2025-12-31 21:56:53 +01:00

Update kInit version and add metadata to analyze script a97a851cd1

- Updated version number in kInit.sh from 3.1 to 3.2.
- Modified last modified date in kInit.sh to 2025/12/31.
- Added metadata including name, author, creation date, and version to analyze.sh, marking it as version 1.0.

Update checksums and enhance module result handling in kInit cc3eaeb3d1

- Updated checksums for modified scripts in checksums.sha256.
- Improved module result handling in kInit.sh to ensure accurate summary reporting.
- Added conditional checks for MODULE_RESULTS_FILE in utils.sh to enhance flexibility.
- Adjusted output messages in analyze.sh for better clarity on verification results.

kleb commented

2026-01-02 07:55:53 +01:00

Author

Owner

/review

kAgent commented

2026-01-02 07:56:06 +01:00

Collaborator

Persistent review updated to latest commit e46f30afe0

**[Persistent review](https://git.kleb.sh/kleb/kInit/pulls/21#issuecomment-188)** updated to latest commit https://git.kleb.sh/kleb/kInit/commit/e46f30afe00afd6a23e9bb3ce645ce4e678a2191

kleb changed title from ~~WIP: Add analyze mode and summary reporting to kInit~~ to Add analyze mode and summary reporting to kInit

2026-01-02 09:45:17 +01:00

kleb merged commit eb10296048 into main

2026-01-02 09:45:23 +01:00

kleb deleted branch feature/analyse

2026-01-02 09:45:23 +01:00

kleb referenced this pull request from a commit

2026-01-02 09:45:23 +01:00

Merge pull request 'Add analyze mode and summary reporting to kInit' (#21) from feature/analyse into main

kleb referenced this pull request from a commit

2026-08-24 01:37:12 +02:00

Merge pull request 'Add analyze mode and summary reporting to kInit' (#21) from feature/analyse into main