feat: improve bootstrap and README portability

[cuberhaus]

Summary

• Make bootstrap initialization Stow-aware, idempotent, and safe for fresh checkouts, including conflict backup support.
• Add the requested wrapped visual-line mappings for Doom Org mode.
• Replace remote README operating-system images with local assets.

Validation

• Bootstrap Stow tests passed.
• Shell syntax checks passed.
• README Markdownlint passed.

Closes #13

Related to #47 and #71. They remain open for manual Doom behavior verification and GitHub iOS rendering verification respectively.

[cursor]

Security review — PR #72

Result: No high-confidence vulnerabilities found.

Reviewed the bootstrap/stow portability changes, stow-backup-conflicts dry-run support, tests, README asset swap, and Doom Emacs config tweak against injection, authz, secrets handling, unsafe deserialization, SSRF/XSS, and supply-chain risk.

Scope reviewed

Area	Files
Bootstrap entrypoints & shared logic	.local/scripts/bootstrap/{arch,manjaro,ubuntu,ubuntu_windows,mac,work}, base_functions, *_functions
Stow conflict handling	.local/scripts/stow-backup-conflicts
Tests	tests/test_bootstrap_stow.sh
Docs / config	README.md, .doom.d/config.el, Makefile

Positive security posture (not findings)

1. Explicit consent before linking — bootstrap_stow_checkout requires an interactive TTY and user confirmation (bootstrap_confirm_stow) before running stow-backup-conflicts or applying links. Unattended/non-interactive runs skip Stow entirely rather than assuming consent (--no-stow also supported). This reduces accidental or unattended file overwrites during provisioning.
2. Checkout-relative sourcing — Bootstrap entrypoints resolve DOTFILES_ROOT from BASH_SOURCE and source helpers from the running checkout instead of $HOME/.local/scripts, avoiding a chicken-and-egg dependency on pre-stowed paths.
3. Profile allowlist for package install — bootstrap_install_stow uses a case statement over fixed profile names; the profile argument is only ever a hardcoded literal from each entrypoint, so there is no user-controlled command injection surface.
4. Quoted path usage — Paths ($dotfiles_root, $HOME, $parent_dir, $package_name) are consistently double-quoted in stow invocations and bash calls.
5. README asset change — OS icons moved from external hotlinks to repo-local .github/assets/os-icons/*.png, reducing third-party supply-chain / availability risk in rendered docs.

Uncertain / low-confidence notes (not confirmed vulnerabilities)

1. Conflict path normalization (pre-existing pattern, expanded call surface) — stow-backup-conflicts builds src="$TARGET/$rel" and dest="$BACKUP_DIR/$rel" from Stow dry-run output without rejecting .. segments. GNU Stow conflict lines for a normal dotfiles package should only contain package-relative paths (e.g. .bashrc), so traversal outside $HOME is unlikely in practice. Assumption: the stow binary on PATH is trustworthy. Validation: confirm Stow never emits ..-containing conflict paths for this package layout; optionally harden with a canonical-path check before mv.
2. DOTFILES_ROOT override in bootstrap_repository_root() — The helper honors a pre-set DOTFILES_ROOT when the directory exists. Official entrypoints overwrite this from BASH_SOURCE before use, so environment injection via entrypoints is not a practical vector. Direct sourcing of base_functions outside entrypoints could honor a caller-set DOTFILES_ROOT; that is intentional for tests and matches existing ${DOTFILES_ROOT:-$HOME} usage elsewhere.

Areas with no issues found

• Command / SQL / template injection — No eval, unquoted expansions into shell metacharacters, or dynamic code execution from user/PR inputs.
• Secrets & logging — No credentials, tokens, or sensitive env vars added; preview output is printed, not evaluated.
• Authn/authz — N/A (local provisioning scripts, not a network service).
• SSRF / XSS — No new outbound requests; README uses static local image paths.
• Dependencies — No new third-party packages; only installs stow via existing OS package managers (same privilege model as the rest of bootstrap).
• .doom.d/config.el — Evil/Org keybinding remap only; no security impact.

Conclusion

This PR improves bootstrap safety around Stow (confirmation gate, non-interactive opt-out) and does not introduce confirmed exploitable vulnerabilities in the reviewed diff. The only residual hardening opportunity is optional path canonicalization in stow-backup-conflicts, which predates this change and is low likelihood.

  

_{Sent by Cursor Automation: Find vulnerabilities}