[mimosa 1.0.3] Reproducible findings: git-gate project-root resolution, GLM gate credential integration gap, static FP/safe-control calibration

Start with the documented commands and entry points: mimosa status --project ., the ZCode PreToolUse(Bash) git-gate, mimosa doctor, and the gate configuration surfaces. Review .zcode-plugin/plugin.json, dist/cli.js, and related issue #43, then reproduce the listed contract fixtures. Done means the proposed root resolution, credential or host-model flow, finding calibration, and suppression behavior are covered by the suggested acceptance tests.

Additional reproducible findings from Mimosa 1.0.3 on Windows / ZCode

We completed a security-gate investigation on a private PHP/Python application and can add several reproducible data points to this issue.

No protected Mimosa payload was modified, no hook was disabled, and no --no-verify / MIMOSA_NO_GIT_GATE / hook-path override was used.

1. Git-gate project-root resolution differs from the CLI

In an existing multi-repository ZCode workspace:

• mimosa status --project . correctly resolved an isolated repository passed from the command working directory.
• the ZCode PreToolUse(Bash) git-gate continued scanning a different repository bound to the ZCode workspace.

This was reproduced multiple times.

After completely closing ZCode and starting a fresh process whose only workspace was the isolated repository, both the CLI and hook correctly bound to the isolated repository.

So the issue appears specifically related to git-gate project-root resolution from the ZCode host workspace rather than command cwd.

Expected behavior would be equivalent to resolving the actual target Git root, e.g. git rev-parse --show-toplevel, for the commit/push operation.

2. MIMOSA_GIT_GATE_GLM=1 is not usable with the documented configuration surface

In the fresh isolated workspace:

• MIMOSA_GIT_GATE_GLM=1 was inherited by the ZCode process;
• the normal L3 git gate executed;
• static findings were detected;
• semantic review did not execute and the output indicated no usable key (未复核/无 Key);
• the gate correctly remained fail-closed.

We then exhaustively checked the supported configuration surfaces without inspecting secrets or modifying protected payloads:

• mimosa --help
• mimosa doctor
• mimosa doctor --json
• mimosa audit --help
• mimosa mcp --help
• installed English/Chinese README files
• commands
• skills
• manifests
• readable CLI/bootstrap files

We found no documented:

• GLM provider setting;
• GLM model setting;
• API-key environment variable;
• endpoint variable;
• configure, auth, login, or setup command;
• schema or supported creator for the runtime.json path mentioned by doctor.

The ZCode host itself had a functional GLM provider, but Mimosa did not consume that host configuration.

This leaves MIMOSA_GIT_GATE_GLM=1 effectively unusable for this installation unless there is an undocumented credential-integration mechanism.

3. Static false positives reproduced with safe counterparts and unsafe controls

We built an engine contract suite using minimal fixtures.

Safe/by-design cases still reported as HIGH included:

• validated internal redirect helper whose contract rejects external scheme/host/userinfo/fragment/CRLF/protocol-relative destinations;
• OAuth authorization redirect where provider is enum/allowlisted and the authorization-server origins are server-side literal constants;
• RFC 6238 TOTP using HMAC-SHA1;
• test/tooling filesystem operations confined to temporary directories.

The corresponding unsafe controls were still correctly blocked:

• header('Location: ' . $_GET['url']) → HIGH / commit denied;
• tainted shell string with shell=True → HIGH / write or commit denied.

So the problem is not lack of enforcement; it is inability to distinguish supported safe protocol/sanitizer contexts from truly unsafe sinks.

4. Crypto rule appears miscalibrated in both directions

A TOTP HMAC-SHA1 implementation validated against RFC 6238 vectors is classified as weak crypto.

However, a minimal sha1($password) password-hashing fixture was not classified as HIGH in the same contract suite.

Expected behavior:

• TOTP/HOTP HMAC-SHA1 protocol compatibility → allowed or contextual informational finding;
• SHA-1 used for password storage → HIGH.

5. Ledger / suppression behavior differs between standalone scan and git gate

Inline suppression / standalone scanning can consider an individual finding resolved or ignored.

The L3 git gate still evaluates those same findings fail-closed.

If this is intentional, it would help to document that ledger/suppression does not participate in git-gate decisions.

If it is not intentional, using one shared policy evaluation path for standalone scan, sealed scan, commit gate, and push gate would eliminate significant ambiguity.

Suggested acceptance tests

A future Mimosa release could include contract fixtures such as:

SAFE_PROCESS_ARGV_LIST        -> no HIGH
UNSAFE_TAINTED_SHELL_STRING  -> HIGH

SAFE_INTERNAL_REDIRECT       -> no HIGH
USER_CONTROLLED_REDIRECT     -> HIGH

OAUTH_LITERAL_ALLOWED_ORIGIN -> no HIGH
OAUTH_USER_CONTROLLED_ORIGIN -> HIGH

TOTP_HMAC_SHA1_RFC6238       -> no HIGH / INFO
PASSWORD_SHA1                -> HIGH

REMOVED_SINK_RESCAN          -> stale finding disappears

GIT_GATE_PROJECT_ROOT        -> scans the repository targeted by commit/push

We can provide additional sanitized reproducer details if useful.

Addendum (found while filing this report)

• The distributed .zcode-plugin/plugin.json official description states: 「深度审计的复核与修复由 ZCode 自身模型完成，无需另配 GLM API Key。」 ("deep-audit review and fixes are performed by ZCode's own model; no separate GLM API Key is required"). However, with MIMOSA_GIT_GATE_GLM=1 the L3 git gate never handed semantic review to the host model — it denied purely on static findings with no host-review flow observed. Either the gate should consume host-model review per that description, or the flag needs a documented key-based path.
• The readable dist/cli.js is only a signed loader (zero occurrences of glm / runtime.json); the actual logic lives in the Ed25519-verified encrypted payloads. doctor flags ~/.zcode/mimosa-zcode/runtime.json as missing, but no readable artifact documents its schema, creator, or creating command.

Related: #43 (policy evaluation paths for gate vs standalone scan).

Environment:

Mimosa: 1.0.3
Host: ZCode
OS: Windows
Git gate: graded / fail-closed
GLM gate flag: MIMOSA_GIT_GATE_GLM=1