Kqan git patch 2

[tthphat]

No description provided.

[bitdive-review]

BitDive Runtime Review - PR #1600

PR: #1600
Branch: kqanGit-patch-2 -> main
Method: BitDive runtime trace comparison + direct HTTP verification + targeted code inspection
Verdict: APPROVE WITH NOTES
Confidence: High — runtime change exhaustively verified; security notes are code-inspection only

Summary

This PR contains three changes: a new Jenkins CI pipeline (Jenkinsfile), a hardcoded fake AWS key injected as dead code in MediaController.getFile (unused local variable), and a trailing newline removal in TaxApplication.java. Runtime trace pairs on both the changed method and a sibling endpoint confirm zero behavioral divergence — identical execution trees, identical SQL, zero writes, zero downstream calls. The hardcoded secret string is a security anti-pattern that should be removed before merge, even though it has no runtime effect. The Jenkinsfile Gitleaks stage is non-blocking (returnStatus: true), which limits its effectiveness as a secret-detection gate.

Runtime Verification Matrix

Area	Result	Behavior Δ	Meaning	Evidence
MediaController.getFile	Stable	zero contract drift (200 · 1 SQL read · 4-node tree · 0 writes)	Dead-code injection has no runtime effect	before / after
MediaController.get (sibling)	Stable	zero contract drift (200 · 1 SQL · 4-node tree)	Adjacent endpoint unaffected	before / after
Jenkinsfile CI pipeline	Code only	Gitleaks non-blocking · HEAD~1 diff scope · Java 25 match	CI concerns, not runtime	code inspection
TaxApplication.java	Code only	trailing newline removal only	No semantic change	code inspection

How to read BitDive evidence

Behavior Δ (matrix) and the diff blocks inside each Change are the contract summary.
Evidence links open the full BitDive share: call tree · SQL · writes · downstream · first divergence.

• Trace pair — full trees compared
• Code only — inspection only, no runtime trace

Review scope and validation coverage

media
  -> MediaController.getFile()           [dead-code injection — trace verified]
  -> MediaController.get()                [sibling stability check — trace verified]
  -> MediaRepository.findById
  -> FileSystemRepository.getFile

CI infrastructure
  -> Jenkinsfile                          [code analysis — new pipeline]

tax
  -> TaxApplication.java                  [whitespace only — out of scope]

Behavior	Scenario	Evidence	Status
getFile dead-code injection	GET /media/medias/1/file/phone_category.jpg	Trace pair	Stable (zero drift)
Sibling endpoint stability	GET /media/medias/1	Trace pair	Stable (zero drift)
Jenkinsfile CI pipeline	Code inspection	Code only	Concerns noted
TaxApplication whitespace	Code inspection	Code only	No change

Note: values.yaml was identified during review but is not part of the actual PR diff (three-dot merge-base to head). The #gitleaks:allow annotations exist on main but were never present on the PR branch — they are a branch-divergence artifact, not a PR-introduced change.

Change #1 — MediaController.getFile: dead-code injection (zero behavioral change)

The PR adds a comment (// Test Gitleaks scan) and an unused String aws_secret variable containing a fake AWS key pattern at line 94 of MediaController.getFile(). The variable is assigned but never referenced — dead code with no execution-path impact.

Behavior contract

# GET /media/medias/1/file/phone_category.jpg — runtime contract
  HTTP 200 OK (both sides)
  SQL READ MediaRepository.findById (1 query, identical text)
  writes: 0 (read-only GET)
  downstream: 0 REST calls
  tree: 4 nodes both sides
    MediaController.getFile
    -> MediaServiceImpl.getFile
       -> MediaRepository.findById
       -> FileSystemRepository.getFile
# first divergence: none (contracts equivalent)
# JVM Lambda memory address only: 0x74358218 -> 0x8331f368 (startup artifact)

Scenario matrix

Scenario	Before PR	After PR	Purpose
getFile (changed method)	200, 8.57ms	200, 94.68ms cold / 10.89ms warm	Prove dead code has no effect
get (sibling endpoint)	200, 4.58ms	200, 102.75ms	Confirm blast radius is isolated

Cold-JVM latency (94.68ms) normalizes to 10.89ms on warm JVM, matching baseline (8.57ms) within normal variance.

Trace evidence

Trace	Scenario	HTTP	SQL	Writes	Result
before getFile	getFile	200	1 read	0	baseline
after getFile	getFile	200	1 read	0	identical contract
warm getFile	getFile	200	1 read	0	latency normalized
before get	get	200	1 read	0	baseline
after get	get	200	1 read	0	identical contract

Contract delta

Layer	Before PR	After PR	Result
HTTP	200	200	stable
SQL	1 read (findById)	1 read (findById)	stable
Persistence	0 writes	0 writes	stable
Downstream	0 REST calls	0 REST calls	stable
Steps	4 nodes	4 nodes	stable
Latency	8.57ms	10.89ms warm	stable (cold-JVM spike resolved)

Key trace delta

First meaningful divergence: none — contracts are equivalent. The only trace difference is a JVM Lambda memory address (InputStreamResource$$Lambda/0x74358218 -> 0x8331f368), which is a JVM class-loading artifact, not a behavioral change.

Change #2 — Jenkinsfile: CI pipeline (code analysis)

New CI pipeline with Gitleaks Scan, Detect Changes, Build, Test, Snyk Scan, SonarQube Analysis, and Quality Gate stages.

Findings

Item	Detail	Concern
Gitleaks stage	returnStatus: true + echo warning only	Non-blocking — secret-like patterns detected but pipeline continues
Detect Changes	git diff HEAD~1 HEAD	Not PR-aware — multi-commit PRs may have incomplete service detection
Java version	JAVA_HOME=25.0.2-tem	Matches pom.xml java.version=25
Snyk Scan	`
Quality Gate	2min timeout, abortPipeline: true	Functional gate
Deploy stage	none	Pipeline builds and tests only

The non-blocking Gitleaks stage is particularly relevant given that this PR introduces a hardcoded secret pattern in MediaController.getFile. The pipeline would detect but not block on it.

Follow-Ups

Type	Item
Security	Remove hardcoded fake AWS key (AKIAIMXFFAFAKEKEY123X+jhG762skalAQWERT) from MediaController.getFile line 94 — dead code, security anti-pattern
CI hardening	Make Jenkinsfile Gitleaks stage blocking (remove returnStatus: true) so secret-like patterns actually fail the build
CI correctness	Replace HEAD~1 diff in Detect Changes with PR-aware merge-base for multi-commit PRs
Merge readiness	GitHub reports merge blocked — resolve before merging

Recommendation

Approve with notes. Runtime behavior is verified unchanged by trace pairs on both the modified method and a sibling endpoint — identical 4-node execution trees, identical SQL, zero writes, zero downstream calls. The hardcoded secret string in MediaController.getFile is dead code with no runtime effect but should be removed before merge as a security best practice. The Jenkinsfile Gitleaks stage should be made blocking to catch secret-like patterns in future PRs.