Conversation
…ing Statistics API
…riabile Scenario[GET_ESERVICES_CATALOG]
…GET_ESERVICE_MAIN_DATA]
…eature/QA-11072-probing # Conflicts: # interop-qa-tests/src/test/resources/it/pagopa/pn/cucumber/probing/probing.feature
… con populate_eservice.sql
|
|
||
| private static String md5Hex(String s) { | ||
| try { | ||
| MessageDigest md = MessageDigest.getInstance("MD5"); |
Check failure
Code scanning / CodeQL
Use of a potentially broken or risky cryptographic algorithm High test
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 1 day ago
In general, to fix the problem, replace the use of MD5 with a strong modern hash algorithm (for example, SHA-256). When the hash output length changes, carefully adapt any code that depends on the output length (e.g., substring indices or buffer sizes) to maintain the same functional behavior (here, generating a UUID string).
In this specific code, the only risky construct is MessageDigest.getInstance("MD5") within md5Hex. The method currently returns a 32-character hex string (128-bit MD5). uuidFromLongSeed then slices this 32-character string into UUID components. To remove MD5 while preserving the 32-character expectation, we can:
- Change the digest algorithm to
"SHA-256". - Compute the SHA-256 digest (32 bytes, 64 hex chars).
- Hex-encode the full digest but then take only the first 32 characters to feed into the existing UUID-splitting logic.
This keepsuuidFromLongSeedunchanged, maintains deterministic UUIDs for the same seed, and replaces MD5 with SHA-256. We should also adjust the error message thrown in the catch block to reference SHA-256 instead of MD5.
Changes required in interop-qa-tests/src/test/java/it/pagopa/pn/interop/cucumber/steps/probing/model/EserviceRow.java:
- In
md5Hex, replace"MD5"with"SHA-256", rename the method to a more generic name (e.g.,sha256Hex32), update theStringBuilderinitial capacity and error message, and truncate the result to 32 hex characters. - Update the call site in
uuidFromLongSeedto use the new method name.
No new imports are needed, since MessageDigest and StandardCharsets are already imported.
| @@ -225,7 +225,7 @@ | ||
| // ------------------------ | ||
|
|
||
| private static UUID uuidFromLongSeed(long seed) { | ||
| String hex32 = md5Hex(Long.toString(seed)); // md5(seed::text) su Postgres | ||
| String hex32 = sha256Hex32(Long.toString(seed)); // derived from seed::text | ||
| String uuidStr = | ||
| hex32.substring(0, 8) + "-" + | ||
| hex32.substring(8, 12) + "-" + | ||
| @@ -235,15 +235,18 @@ | ||
| return UUID.fromString(uuidStr); | ||
| } | ||
|
|
||
| private static String md5Hex(String s) { | ||
| private static String sha256Hex32(String s) { | ||
| try { | ||
| MessageDigest md = MessageDigest.getInstance("MD5"); | ||
| MessageDigest md = MessageDigest.getInstance("SHA-256"); | ||
| byte[] digest = md.digest(s.getBytes(StandardCharsets.UTF_8)); | ||
| StringBuilder sb = new StringBuilder(32); | ||
| for (byte b : digest) sb.append(String.format("%02x", b)); | ||
| return sb.toString(); | ||
| StringBuilder sb = new StringBuilder(64); | ||
| for (byte b : digest) { | ||
| sb.append(String.format("%02x", b)); | ||
| } | ||
| // Use the first 32 hex characters (128 bits) for UUID derivation | ||
| return sb.substring(0, 32); | ||
| } catch (Exception e) { | ||
| throw new RuntimeException("MD5 not available", e); | ||
| throw new RuntimeException("SHA-256 not available", e); | ||
| } | ||
| } | ||
| } |
...a-tests/src/test/java/it/pagopa/pn/interop/cucumber/steps/probing/utils/ProbingResolver.java
Fixed
Show fixed
Hide fixed
...a-tests/src/test/java/it/pagopa/pn/interop/cucumber/steps/probing/utils/ProbingResolver.java
Fixed
Show fixed
Hide fixed
|
|
||
| // 4) applica delta | ||
| if (baseValue == null) return null; | ||
| return baseValue + delta; |
Check failure
Code scanning / CodeQL
Uncontrolled data in arithmetic expression High test
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI about 7 hours ago
General fix approach: ensure that the arithmetic baseValue + delta cannot overflow the Integer range by either (a) guarding the addition with explicit bounds checks or (b) using a wider type and/or clamping. Since the method returns Integer and current behavior on overflow is unspecified, the safest non‑breaking change is to add checks before performing the addition and either clamp to Integer.MAX_VALUE/Integer.MIN_VALUE or throw an exception.
Best specific fix here: before returning baseValue + delta in ProbingResolver.resolveFrequency, introduce explicit guard logic:
- If
deltais positive andbaseValue > Integer.MAX_VALUE - delta, returnInteger.MAX_VALUE. - If
deltais negative andbaseValue < Integer.MIN_VALUE - delta, returnInteger.MIN_VALUE. - Otherwise, safely return
baseValue + delta.
This keeps the return type and usage the same, avoids overflow, and for “normal” values yields exactly the same result. No new imports or other methods are required; we only alter the body of resolveFrequency in ProbingResolver.java.
Concretely:
- Edit
interop-qa-tests/src/test/java/it/pagopa/pn/interop/cucumber/steps/probing/utils/ProbingResolver.java. - Replace the last lines of
resolveFrequency(theif (baseValue == null) ... return baseValue + delta;) with a guarded implementation as described.
No changes are needed in StepParser or AbstractResolver for this specific overflow.
| @@ -111,9 +111,16 @@ | ||
| null | ||
| ); | ||
|
|
||
| // 4) applica delta | ||
| // 4) applica delta, evitando overflow | ||
| if (baseValue == null) return null; | ||
| return baseValue + delta; | ||
| int base = baseValue; | ||
| if (delta > 0 && base > Integer.MAX_VALUE - delta) { | ||
| return Integer.MAX_VALUE; | ||
| } | ||
| if (delta < 0 && base < Integer.MIN_VALUE - delta) { | ||
| return Integer.MIN_VALUE; | ||
| } | ||
| return base + delta; | ||
| } | ||
|
|
||
| public Duration resolveSchedulerInterval(String row) { |
No description provided.