ElyOffice/tasks/reviews/C01.2a-r3.md

FAIL

Checks run: cargo check --workspace, cargo clippy --workspace --all-targets and cargo fmt --check are all clean, and cargo test --workspace passes 5 tests. tests/scripts/bundle-macos.sh, desktop-files.sh, installer-windows.sh, appimage-pins.sh and apps-start.sh all pass, and none is skipped. Every file is under 500 lines.

Round 2 defects:

1. appimage.sh, the hand-made AppDir copies: fixed. Only the desktop entry is written, into $work. linuxdeploy places the binary, the desktop file, the icon and AppRun.
2. installer-windows.sh:2, the comment length: fixed. It is now ten words.
3. installer-windows.sh, the substring grep for crt-static: fixed. The test now reads the effective cfg for the msvc target. I checked that it can fail: RUSTFLAGS="" cargo rustc -p ely-platform --lib --target x86_64-pc-windows-msvc -- --print cfg drops target_feature="crt-static", so grep exits 1. Without the override, the line is present.

New defects:

1. packaging/linux/appimage.sh:76 — appimagetool is called without --runtime-file. In appimagetool 1.9.1 (src/appimagetool.c, src/appimagetool_fetch_runtime.cpp), a missing runtime file makes it download https://github.com/AppImage/type2-runtime/releases/download/continuous/runtime-$arch at build time. That URL is a moving tag, and the tool checks only HTTP 200 and the content length, with no hash. This runtime becomes the executable header of every AppImage we ship. It is the one binary the recipe pulls without a pin, and tests/scripts/appimage-pins.sh:2 ("Every AppImage tool the recipe downloads matches its pinned hash") states the opposite, with no evidence. Failing scenario: upstream pushes a new continuous runtime, whether broken or compromised. The next appimage.sh ely-doc embeds it silently, so two builds of the same commit produce different AppImages, and nothing fails. Fix: pin a dated type2-runtime release per architecture and check it with fetch_tool against a sha256. Pass it with --runtime-file. Add the runtime URLs to appimage-pins.sh.

2. tests/scripts/installer-windows.sh:33-34 — cfg=$(... cargo rustc ... 2>&1) drops cargo's exit status. Any cargo failure then falls through to the grep and is reported as "the msvc build links the C runtime dynamically". Cargo's real error is swallowed and a wrong cause is shown (rule 2). Failing scenario: a dependency added later fails to compile for x86_64-pc-windows-msvc, or the registry cannot be reached. The test fails with the crt-static message, and the developer hunts in .cargo/config.toml for a problem that is not there. Fix: make a non-zero cargo exit fail the test with cargo's own output (for example cfg=$(...) || fail "cargo rustc for msvc failed: $cfg"), and grep only after it succeeds.