merge releases-1.4.x branch into the develop branch

[nagendra0721]

Summary by CodeRabbit

• New Features

  • Added caching mechanism for cryptographic operations and certificate trust paths.
  • Introduced new exception handling for improved error reporting.

• Performance

  • Optimized cryptographic primitive initialization using thread-local instances.
  • Improved response body handling for better memory efficiency.

• Bug Fixes

  • Corrected certificate validation error codes.
  • Enhanced certificate trust verification logic.

• Documentation

  • Updated deployment and setup instructions.

• Chores

  • Bumped version to 1.4.1-rc.1 across services and dependencies.

[coderabbitai]

Walkthrough

Docs updated; DB scripts add indexes and migrations; Helm/deploy scripts bump to 1.4.1-rc.1; Docker/startup adjusted; major Java refactors for crypto (thread-locals), trust validation, utilities, and ZK crypto; partner/signature services updated; widespread DateUtils2 migration; tests adapted; Maven versions/plugins updated.

Changes

Core 1.4.1-rc.1 upgrade and crypto refactor

Layer / File(s)	Summary
End-to-end schema, runtime, crypto, trust, and tests README.md, db_*, deploy/*, helm/**, kernel/**	All release updates: DB indexes/migrations, chart/version bumps, Docker/start scripts, core crypto thread-localization, trust/response handling, partner/signature/ZK flows, DateUtils2 migration, and comprehensive test updates.

Sequence Diagram(s)

sequenceDiagram
  participant ComponentA
  participant ComponentB
  ComponentA->>ComponentB: observable interaction

Loading

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~120 minutes

Poem

A rabbit taps the timing logs, tick-tick—OK!
Helm charts hop to rc.1, we’re on our way.
Ciphers curl in thread-local burrows tight,
Trust paths cached, the signatures alight.
Indices sprout in soil of SQL rows,
Tests nibble carrots—green bars grow.
Ship it, ears high, where the keywind blows! 🐇🔑✨

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

[coderabbitai]

Actionable comments posted: 16

Note

Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (5)

kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/partnercertservice/service/impl/PartnerCertificateManagerServiceImpl.java (2)

314-329: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Keep malformed P7B input on the validation path.

CryptoUtil.decodeURLSafeBase64(certificateData) now runs before the catch that maps bad certificate input to PartnerCertManagerException. If decode fails, callers get an unhandled server error instead of the existing INVALID_CERTIFICATE response.

Suggested fix

-        byte[] p7bBytes= CryptoUtil.decodeURLSafeBase64(certificateData);
-        try (ByteArrayInputStream certStream = new ByteArrayInputStream(p7bBytes)) {
+        try {
+            byte[] p7bBytes = CryptoUtil.decodeURLSafeBase64(certificateData);
+            try (ByteArrayInputStream certStream = new ByteArrayInputStream(p7bBytes)) {
+                CertificateFactory cf = CertificateFactory.getInstance("X.509");
+                Collection<?> p7bCertList = cf.generateCertificates(certStream);
+                p7bCertList.forEach(cert -> certList.add((Certificate) cert));
+                Collections.reverse(certList);
+                return certList;
+            }
+        } catch (Exception exp) {
-            CertificateFactory cf = CertificateFactory.getInstance("X.509");
-            Collection<?> p7bCertList = cf.generateCertificates(certStream);
-            p7bCertList.forEach(cert -> {
-                certList.add((Certificate)cert);
-            });
-            Collections.reverse(certList);
-            return certList;
-        } catch(CertificateException | IOException  exp) {
             LOGGER.error(PartnerCertManagerConstants.SESSIONID, PartnerCertManagerConstants.UPLOAD_CA_CERT,
                 PartnerCertManagerConstants.EMPTY, "Error Parsing P7B Certificate data.", exp);
         }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/partnercertservice/service/impl/PartnerCertificateManagerServiceImpl.java`
around lines 314 - 329, The decode step
(CryptoUtil.decodeURLSafeBase64(certificateData)) happens outside the try/catch,
so a bad Base64 will throw before the CertificateException/IOException handler
and not be mapped to PartnerCertManagerException; move the decode into the
existing try block (or add a surrounding try that catches
IllegalArgumentException/RuntimeException from decoding) so any decode failure
is caught and handled exactly like the CertificateException/IOException,
returning the INVALID_CERTIFICATE PartnerCertManagerException; reference
CryptoUtil.decodeURLSafeBase64, certificateData, the try block that calls
CertificateFactory.generateCertificates, LOGGER and
PartnerCertManagerErrorConstants.INVALID_CERTIFICATE to locate and update the
code.

---

179-199: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Initialize certChainCache independently of disableTrustStoreCache.

When mosip.kernel.partner.truststore.cache.disable=true, init() skips certChainCache, but getCertificateTrustPath(...) still calls certChainCache.get(...) on every request. That makes trust validation and partner-certificate upload paths fail with a null-pointer as soon as the trust-store cache is disabled.

Suggested fix

     public void init() {
         // Added Cache2kBuilder in the postConstruct because expire value
         // configured in properties are getting injected after this object creation.
         // Cache2kBuilder constructor is throwing error.
         checkAndUpdateCaCertificateTypeIsNull();
+        certChainCache = new Cache2kBuilder<String, List<Certificate>>() {}
+                .name("certChainCache-" + this.hashCode())
+                .expireAfterWrite(certChainCacheExpireInMin, TimeUnit.MINUTES)
+                .entryCapacity(100)
+                .build();
+
         if (!disableTrustStoreCache) {
                 caCertTrustStore = new Cache2kBuilder<String, Object>() {}
                 .name("caCertTrustStore-" + this.hashCode())
                 .expireAfterWrite(cacheExpireInMins, TimeUnit.MINUTES)
                 .entryCapacity(10)
@@
-            certChainCache = new Cache2kBuilder<String, List<Certificate>>() {}
-                    .name("certChainCache-" + this.hashCode())
-                    .expireAfterWrite(certChainCacheExpireInMin, TimeUnit.MINUTES)
-                    .entryCapacity(100)
-                    .build();
         }
     }

Also applies to: 359-366

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/partnercertservice/service/impl/PartnerCertificateManagerServiceImpl.java`
around lines 179 - 199, The init() currently only creates certChainCache when
disableTrustStoreCache is false, causing getCertificateTrustPath(...) to NPE
when the truststore cache is disabled; change init() so certChainCache is always
initialized regardless of disableTrustStoreCache (move the
Cache2kBuilder<String,List<Certificate>>() { ...
}.name("certChainCache-"+this.hashCode())...build() outside the if or add an
else branch that constructs an equivalent cache), referencing certChainCache,
disableTrustStoreCache and init(); apply the same fix for the duplicated block
around the 359-366 area so certChainCache is never left null.

kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/service/impl/CoseSignatureServiceImpl.java (1)

660-665: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Avoid catching generic Exception.

Widening the catch from IOException to Exception will mask programming errors like NullPointerException or ClassCastException. Catch specific expected exceptions instead.

Proposed fix

-        } catch (Exception e) {
+        } catch (IOException | ClassCastException e) {
             LOGGER.error(SignatureConstant.SESSIONID, SignatureConstant.COSE_VERIFY, SignatureConstant.BLANK,
                     "Error occurred while parsing COSE Sign1 Tagged Content" + e);
             throw new RequestException(SignatureErrorCode.TAGGED_COSE_SIGN1.getErrorCode(),
                     SignatureErrorCode.TAGGED_COSE_SIGN1.getErrorMessage());
         }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/service/impl/CoseSignatureServiceImpl.java`
around lines 660 - 665, The catch-all block in CoseSignatureServiceImpl that
handles parsing the COSE Sign1 Tagged Content (currently "catch (Exception e)"
logging and rethrowing SignatureErrorCode.TAGGED_COSE_SIGN1) should be narrowed
to the specific exceptions thrown by the parsing logic (e.g., IOException,
CborException, IllegalArgumentException or any parsing-specific exceptions from
the COSE/CBOR library used). Replace "catch (Exception e)" with separate catch
clauses for those expected exceptions, keep the existing LOGGER.error and
RequestException rethrow, and remove the generic catch so programming errors
(NullPointerException, ClassCastException, etc.) are not swallowed and can
bubble up.

kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/partnercertservice/test/service/PartnerCertificateManagerServiceTest.java (1)

308-318: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Seed the CA prerequisite before asserting org mismatch.

Line 308 currently calls uploadPartnerCertificate(...) without first uploading a CA chain, so this can pass for the wrong reason if the service fails earlier on trust/root validation instead of organization-name validation. Mirror the minimal setup from testUploadPartnerCertificate_OrganizationMismatch() so this test proves KER-PCM-008 specifically.

Suggested test setup

 `@Test`
 public void testUploadPartnerCertificate_ORG_notMatch() {
+    CACertificateRequestDto caCertRequestDto = new CACertificateRequestDto();
+    caCertRequestDto.setCertificateData(caCertificate);
+    caCertRequestDto.setPartnerDomain("FTM");
+    partnerCertService.uploadCACertificate(caCertRequestDto);
+
     PartnerCertificateRequestDto requestDto = new PartnerCertificateRequestDto();
     requestDto.setCertificateData(interCertificate);
     requestDto.setOrganizationName("MOSIP");
     requestDto.setPartnerDomain("FTM");

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/partnercertservice/test/service/PartnerCertificateManagerServiceTest.java`
around lines 308 - 318, Seed the CA/trust chain before asserting org mismatch:
in testUploadPartnerCertificate_ORG_notMatch(), perform the same minimal CA
setup used in testUploadPartnerCertificate_OrganizationMismatch() (e.g., upload
the CA/root certificate or call the helper that registers the CA) so that the
service passes trust/root validation; then construct the
PartnerCertificateRequestDto (using interCertificate,
setOrganizationName("MOSIP"), setPartnerDomain("FTM")) and call
partnerCertService.uploadPartnerCertificate(requestDto) to assert the
PartnerCertManagerException with error code "KER-PCM-008". Ensure you invoke the
exact CA-seeding helper or method used by the other test so this test fails
specifically on organization-name validation.

kernel/keys-generator/src/main/java/io/mosip/kernel/keygenerator/generator/RandomKeysGenerator.java (1)

136-145: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Fix the refill loop bound.

startIndex is an absolute id, but noOfKeysToGenerate is a count. Once keys already exist, for (int i = startIndex; i < noOfKeysToGenerate; i++) usually runs zero times, so the pool never gets replenished.

Suggested fix

-        Long maxid = dataEncryptKeystoreRepository.findMaxId();
-        int startIndex = maxid == null ? 0 : maxid.intValue() + 1;
+        Long maxid = dataEncryptKeystoreRepository.findMaxId();
+        int startIndex = maxid == null ? 0 : maxid.intValue() + 1;
+        int endIndexExclusive = startIndex + noOfKeysToGenerate;
@@
-        for (int i = startIndex; i < noOfKeysToGenerate; i++) {
+        for (int i = startIndex; i < endIndexExclusive; i++) {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/keys-generator/src/main/java/io/mosip/kernel/keygenerator/generator/RandomKeysGenerator.java`
around lines 136 - 145, The loop uses startIndex (an absolute ID) against
noOfKeysToGenerate (a count), causing zero iterations when keys already exist;
update the refill loop in RandomKeysGenerator so it generates the requested
count instead of comparing IDs. Replace the for condition "for (int i =
startIndex; i < noOfKeysToGenerate; i++)" with a bound based on count (e.g.,
compute endIndex = startIndex + noOfKeysToGenerate or loop until generatedCount
< noOfKeysToGenerate) so the code using startIndex, noOfKeysToGenerate,
keyGenerator.init(...), secureRandomThreadLocal, and
dataEncryptKeystoreRepository.findMaxId() actually produces the specified number
of new keys.

🟡 Minor comments (13)

README.md-141-143 (1)

141-143: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Add a language to the fenced deployment snippet.

This fence is missing a language identifier, which triggers markdownlint and breaks consistency with the rest of the README.

Suggested diff

-    * ```
+    * ```bash
     export KUBECONFIG=~/.kube/<my-cluster.config>
     ```

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@README.md` around lines 141 - 143, Update the fenced code block containing
the export KUBECONFIG line to include a language identifier (e.g., "bash") so
markdownlint passes and it matches other snippets; locate the fenced block
around the export KUBECONFIG=~/.kube/<my-cluster.config> line in README.md and
change the opening triple backticks to include bash (```bash).

db_upgrade_scripts/mosip_keymgr/sql/1.2.0.1_to_1.2.1.0_rollback.sql-1-1 (1)

1-1: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Fix \echo to not print literal $CURRENT_VERSION/$UPGRADE_VERSION

db_upgrade_scripts/mosip_keymgr/sql/1.2.0.1_to_1.2.1.0_rollback.sql uses \echo '... $CURRENT_VERSION ... $UPGRADE_VERSION', but psql will not substitute $... inside that quoted string (psql variable substitution uses :var, and upgrade.sh doesn’t pass -v CURRENT_VERSION/UPGRADE_VERSION to psql -f).
Switch the message to :CURRENT_VERSION/:UPGRADE_VERSION and add corresponding -v values in upgrade.sh, otherwise the output is misleading during troubleshooting.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@db_upgrade_scripts/mosip_keymgr/sql/1.2.0.1_to_1.2.1.0_rollback.sql` at line
1, The rollback SQL currently prints literal $CURRENT_VERSION/$UPGRADE_VERSION
because psql variable syntax is :var not $var; update
db_upgrade_scripts/mosip_keymgr/sql/1.2.0.1_to_1.2.1.0_rollback.sql to use \echo
'Upgrade Queries not required for transition from :CURRENT_VERSION to
:UPGRADE_VERSION' (or equivalent with :CURRENT_VERSION/:UPGRADE_VERSION) and
modify the script that calls psql (upgrade.sh) to pass those variables via psql
-v CURRENT_VERSION="$CURRENT_VERSION" -v UPGRADE_VERSION="$UPGRADE_VERSION" when
invoking psql -f so the placeholders are substituted at runtime.

db_upgrade_scripts/mosip_keymgr/sql/1.3.0_to_1.4.0_upgrade.sql-1-1 (1)

1-1: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Fix psql variable substitution in upgrade echo
psql substitutes variables with :var (e.g., :CURRENT_VERSION), not $var, so the current \echo '... $CURRENT_VERSION ... $UPGRADE_VERSION' will print the literal placeholders. Switch the \echo text to :CURRENT_VERSION/:UPGRADE_VERSION and ensure those psql variables are provided (e.g., via psql -v ... or \set).

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@db_upgrade_scripts/mosip_keymgr/sql/1.3.0_to_1.4.0_upgrade.sql` at line 1,
The \echo line uses shell-style $CURRENT_VERSION/$UPGRADE_VERSION which psql
will not substitute; change the placeholders to psql variable syntax
(:CURRENT_VERSION and :UPGRADE_VERSION) in the \echo string and ensure those
psql variables are set when running the script (e.g., pass them via psql -v
CURRENT_VERSION=... -v UPGRADE_VERSION=... or add \set CURRENT_VERSION ... and
\set UPGRADE_VERSION ... in the script) so the correct versions are printed;
update the literal in the file referencing \echo and the variable names
CURRENT_VERSION and UPGRADE_VERSION accordingly.

db_upgrade_scripts/mosip_keymgr/sql/1.2.0.1_to_1.2.1.0_upgrade.sql-1-1 (1)

1-1: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Fix psql variable interpolation in upgrade \echo

• \echo '... $CURRENT_VERSION ... $UPGRADE_VERSION ...' will output $CURRENT_VERSION/$UPGRADE_VERSION literally in psql (psql expands :var, not $var).
• Pass values into psql (e.g., via psql -v CURRENT_VERSION="$CURRENT_VERSION" -v UPGRADE_VERSION="$UPGRADE_VERSION" ...) and update the SQL to use :CURRENT_VERSION / :UPGRADE_VERSION.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@db_upgrade_scripts/mosip_keymgr/sql/1.2.0.1_to_1.2.1.0_upgrade.sql` at line
1, The \echo line currently uses $CURRENT_VERSION/$UPGRADE_VERSION which psql
will not interpolate; update the SQL to reference psql variables as
:CURRENT_VERSION and :UPGRADE_VERSION (e.g., change "\echo 'Upgrade Queries not
required for transition from $CURRENT_VERSION to $UPRADE_VERSION'" to use
:CURRENT_VERSION/:UPGRADE_VERSION) and ensure the caller invokes psql with
variable bindings like psql -v CURRENT_VERSION="$CURRENT_VERSION" -v
UPGRADE_VERSION="$UPGRADE_VERSION" so psql will expand those values at runtime.

db_upgrade_scripts/mosip_keymgr/sql/1.4.0_to_1.4.1_upgrade.sql-1-1 (1)

1-1: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Fix psql \echo version placeholders in 1.4.0→1.4.1 upgrade SQL

db_upgrade_scripts/mosip_keymgr/upgrade.sh runs the SQL via psql ... -f $UPGRADE_SCRIPT_FILE and only sets -v ON_ERROR_STOP=1—it does not pass CURRENT_VERSION/UPGRADE_VERSION into psql. As a result, this \echo will output the literal $CURRENT_VERSION/$UPGRADE_VERSION text.

Proposed fix

-\echo 'Upgrade Queries not required for transition from $CURRENT_VERSION to $UPGRADE_VERSION'
+\echo 'Upgrade Queries not required for transition from 1.4.0 to 1.4.1'

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@db_upgrade_scripts/mosip_keymgr/sql/1.4.0_to_1.4.1_upgrade.sql` at line 1,
The \echo line uses shell-style $CURRENT_VERSION/$UPGRADE_VERSION placeholders
which psql won't interpolate because upgrade.sh doesn't pass those variables;
replace them with the actual versions so the message is correct. Edit the \echo
statement (the line starting with "\echo 'Upgrade Queries not required for
transition from") to hardcode "1.4.0" and "1.4.1" (or the intended literal
version strings) instead of $CURRENT_VERSION/$UPGRADE_VERSION so psql prints the
real versions when run.

db_upgrade_scripts/mosip_keymgr/sql/1.4.0_to_1.4.1_rollback.sql-1-1 (1)

1-1: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Fix version placeholders in rollback \echo output

psql doesn’t interpolate $CURRENT_VERSION/$UPGRADE_VERSION inside \echo (it uses :var), and upgrade.sh invokes psql -f without passing -v values—so this message will print the placeholders literally. Hardcode the versions for this rollback script.

Proposed fix

-\echo 'Rollback Queries not required for transition from $CURRENT_VERSION to $UPGRADE_VERSION'
+\echo 'Rollback Queries not required for transition from 1.4.0 to 1.4.1'

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@db_upgrade_scripts/mosip_keymgr/sql/1.4.0_to_1.4.1_rollback.sql` at line 1,
The \echo line in the rollback script currently uses shell-style placeholders
$CURRENT_VERSION and $UPGRADE_VERSION which psql won't interpolate; replace them
with the actual version literals for this migration (i.e., hardcode the source
and target versions) so the message reads correctly—update the line containing
\echo and the placeholder symbols ($CURRENT_VERSION, $UPGRADE_VERSION) to the
concrete versions for this rollback script.

kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/dto/SignatureResponseDto.java-28-31 (1)

28-31: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Javadoc and @ApiModelProperty are inconsistent.

The Javadoc was updated to say "signed" but the @ApiModelProperty annotation on line 30 still says "encrypted/decrypted". Update the annotation to match:

Proposed fix

 	/**
 	 * Data signed in BASE64 encoding
 	 */
-	`@ApiModelProperty`(notes = "Data encrypted/decrypted in BASE64 encoding")
+	`@ApiModelProperty`(notes = "Data signed in BASE64 encoding")
 	private String data;

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/dto/SignatureResponseDto.java`
around lines 28 - 31, The `@ApiModelProperty` description for the field "data" in
SignatureResponseDto is inconsistent with its Javadoc; update the notes on the
ApiModelProperty for the private String data field in class SignatureResponseDto
to match the Javadoc (e.g., "Data signed in BASE64 encoding") so the annotation
and Javadoc are consistent.

kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/util/SignatureUtil.java-229-233 (1)

229-233: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Potential sensitive data in error log.

Logging the entire jsonPayload when invalid could expose sensitive information (PII, credentials, etc.) if present in the payload. Consider logging only the length or a generic message.

Proposed fix

 		if (!isDataValid(jsonPayload)) {
 			LOGGER.error(SignatureConstant.SESSIONID, SignatureConstant.JWT_SIGN, SignatureConstant.BLANK,
-					"Invalid JSON Payload Data Provided. Payload: " + jsonPayload);
+					"Invalid JSON Payload Data Provided (null or empty).");
 			return SignatureConstant.BLANK;
 		}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/util/SignatureUtil.java`
around lines 229 - 233, The current error log in SignatureUtil (inside the
isDataValid check) logs the full jsonPayload which may contain sensitive data;
change the LOGGER.error call in the block that uses SignatureConstant.SESSIONID,
SignatureConstant.JWT_SIGN and SignatureConstant.BLANK so it does not emit the
full payload—instead log a generic message and non-sensitive metadata (e.g.,
payload length or a fixed placeholder/hashed value) and keep the same return
SignatureConstant.BLANK; update the LOGGER.error invocation in the same method
to remove jsonPayload from the message and include only safe diagnostic info.

kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/zkcryptoservice/test/ZKCryptoManagerServiceTest.java-771-772 (1)

771-772: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Tighten the multi-reference-id assertion.

This now passes for any non-empty value, so the test no longer verifies that multiple encrypted key blobs are concatenated. A regression to returning only one key would still stay green.

Suggested assertion

-        assertTrue(response.getEncryptedRandomKey().contains(".")
-                || response.getEncryptedRandomKey().length() > 0);
+        assertTrue(response.getEncryptedRandomKey().contains("."));
+        assertEquals(2, response.getEncryptedRandomKey().split("\\.").length);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/zkcryptoservice/test/ZKCryptoManagerServiceTest.java`
around lines 771 - 772, The current assertion on
response.getEncryptedRandomKey() is too weak; update the test to assert that the
encryptedRandomKey contains the concatenation delimiter and actually contains
multiple parts (e.g., require response.getEncryptedRandomKey().contains(".") AND
response.getEncryptedRandomKey().split("\\.").length > 1) so the test fails if
only a single key blob is returned; target the assertion around
response.getEncryptedRandomKey() in ZKCryptoManagerServiceTest.

kernel/keys-migrator/pom.xml-24-25 (1)

24-25: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Duplicate property definition.

central.publishing.maven.plugin.version is defined twice. Remove the duplicate line.

Proposed fix

 		<central.publishing.maven.plugin.version>0.7.0</central.publishing.maven.plugin.version>
-		<central.publishing.maven.plugin.version>0.7.0</central.publishing.maven.plugin.version>

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@kernel/keys-migrator/pom.xml` around lines 24 - 25, The pom defines the Maven
property central.publishing.maven.plugin.version twice; remove the duplicate so
only a single
<central.publishing.maven.plugin.version>0.7.0</central.publishing.maven.plugin.version>
remains (leave one occurrence intact and delete the other) to avoid
conflicting/duplicate property definitions.

kernel/keys-migrator/pom.xml-139-158 (1)

139-158: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Duplicate central-publishing-maven-plugin definition.

The plugin is defined twice with identical configuration. Remove the duplicate block (lines 149-158).

Proposed fix

 			<plugin>
 				<groupId>org.sonatype.central</groupId>
 				<artifactId>central-publishing-maven-plugin</artifactId>
 				<version>${central.publishing.maven.plugin.version}</version>
 				<extensions>true</extensions>
 				<configuration>
 					<publishingServerId>ossrh</publishingServerId>
 					<autoPublish>false</autoPublish>
 				</configuration>
 			</plugin>
-			<plugin>
-				<groupId>org.sonatype.central</groupId>
-				<artifactId>central-publishing-maven-plugin</artifactId>
-				<version>${central.publishing.maven.plugin.version}</version>
-				<extensions>true</extensions>
-				<configuration>
-					<publishingServerId>ossrh</publishingServerId>
-					<autoPublish>false</autoPublish>
-				</configuration>
-			</plugin>

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@kernel/keys-migrator/pom.xml` around lines 139 - 158, Remove the duplicated
central-publishing-maven-plugin block: locate the plugin definition with groupId
"org.sonatype.central" and artifactId "central-publishing-maven-plugin" (the
block that includes publishingServerId "ossrh" and autoPublish "false") and
delete the second occurrence so only one plugin definition remains; ensure the
remaining plugin retains the version property
${central.publishing.maven.plugin.version} and <extensions>true</extensions>.

kernel/keys-migrator/pom.xml-179-222 (1)

179-222: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Duplicate maven-source-plugin definitions.

The plugin is defined twice (lines 179-192 and 209-222) with identical execution IDs, which can cause unpredictable build behavior. Remove the duplicate block.

Proposed fix - remove lines 209-222

 			</plugin>
-			<plugin>
-				<groupId>org.apache.maven.plugins</groupId>
-				<artifactId>maven-source-plugin</artifactId>
-				<inherited>true</inherited>
-				<version>2.2.1</version>
-				<executions>
-					<execution>
-						<id>attach-sources</id>
-						<goals>
-							<goal>jar-no-fork</goal>
-						</goals>
-					</execution>
-				</executions>
-			</plugin>

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@kernel/keys-migrator/pom.xml` around lines 179 - 222, Remove the duplicate
maven-source-plugin block: locate the repeated <plugin> entry with
<artifactId>maven-source-plugin</artifactId> and
<execution><id>attach-sources</id></execution> (the second occurrence) and
delete that entire plugin element so only one maven-source-plugin definition
remains with the attach-sources execution id; ensure the remaining plugin keeps
its <version> and <executions> intact to avoid duplicate execution IDs.

kernel/keys-migrator/pom.xml-193-238 (1)

193-238: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Duplicate maven-javadoc-plugin definitions.

The plugin is defined twice (lines 193-208 and 223-238) with identical execution IDs. Remove the duplicate block.

Proposed fix - remove lines 223-238

 			</plugin>
-			<plugin>
-				<groupId>org.apache.maven.plugins</groupId>
-				<artifactId>maven-javadoc-plugin</artifactId>
-				<version>3.2.0</version>
-				<executions>
-					<execution>
-						<id>attach-javadocs</id>
-						<goals>
-							<goal>jar</goal>
-						</goals>
-					</execution>
-				</executions>
-				<configuration>
-					<doclint>none</doclint>
-				</configuration>
-			</plugin>

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@kernel/keys-migrator/pom.xml` around lines 193 - 238, Remove the duplicate
maven-javadoc-plugin block: locate the repeated <plugin> entry with
<artifactId>maven-javadoc-plugin</artifactId> and
<execution><id>attach-javadocs</id></execution> (the second identical block) and
delete it so only one maven-javadoc-plugin definition remains with the
attach-javadocs execution and <doclint>none</doclint> configuration.

🧹 Nitpick comments (9)

kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/crypto/jce/core/CryptoCore.java (3)

129-131: ⚡ Quick win

Public static mutable fields expose internal state.

SYMMETRIC_ALGO and ASYMMETRIC_ALGO are public static non-final fields set during @PostConstruct. This breaks encapsulation and could cause issues if accessed before init() runs (returning null).

♻️ Consider making these package-private or providing getter methods

-    public static String SYMMETRIC_ALGO;
-    public static String ASYMMETRIC_ALGO;
+    private static String symmetricAlgo;
+    private static String asymmetricAlgo;
+
+    public static String getSymmetricAlgo() {
+        return symmetricAlgo;
+    }
+
+    public static String getAsymmetricAlgo() {
+        return asymmetricAlgo;
+    }

Update init() accordingly and ensure callers use the getter methods.

Also applies to: 138-139

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/crypto/jce/core/CryptoCore.java`
around lines 129 - 131, SYMMETRIC_ALGO and ASYMMETRIC_ALGO are public mutable
static fields set in init(), which exposes internal state and can be null before
`@PostConstruct` runs; make them non-public (package-private or private) and
provide public static getter methods (e.g., getSymmetricAlgo(),
getAsymmetricAlgo()), update init() to set the private fields, and refactor any
callers to use the new getters so access is safe and encapsulated.

---

250-256: 💤 Low value

Length validation uses incorrect minimum bound.

The validation data.length <= ivLength + (tagLength / 8) checks that data is longer than IV + tag, but for GCM with 16-byte IV and 128-bit (16-byte) tag, minimum valid ciphertext is actually just the tag (if plaintext is empty). The check should be data.length < ivLength + (tagLength / 8) (strict less-than) to allow zero-length plaintext encryption.

However, this is a minor edge case since empty plaintext encryption is rare.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/crypto/jce/core/CryptoCore.java`
around lines 250 - 256, The length check in CryptoCore around ivLength (from
cipher.getBlockSize()) and tagLength currently uses <= which wrongly rejects
valid ciphertexts with empty plaintext; update the validation in the method
containing this logic to use a strict less-than (change the condition from
data.length <= ivLength + (tagLength / 8) to data.length < ivLength + (tagLength
/ 8)) so zero-length plaintext encryptions (IV + tag only) are allowed, keeping
the same InvalidDataException and
SecurityExceptionCodeConstant.MOSIP_INVALID_DATA_LENGTH_EXCEPTION usage.

---

124-127: 💤 Low value

Thread-local Cipher fields use non-standard naming convention.

Instance-level ThreadLocal fields use UPPER_CASE naming (lines 125-127), which conventionally indicates constants. Since these are not compile-time constants and are initialized in @PostConstruct, consider using standard camelCase naming for clarity.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/crypto/jce/core/CryptoCore.java`
around lines 124 - 127, The three instance ThreadLocal fields
CIPHER_GCM_ENCRYPT_DECRYPT_SYMMETRIC, CIPHER_GCM_ENCRYPT_DECRYPT_ASYMMETRIC, and
SK_FACTORY_PBKDF2 should be renamed to camelCase (e.g.,
cipherGcmEncryptDecryptSymmetric, cipherGcmEncryptDecryptAsymmetric,
skFactoryPbkdf2) to avoid implying constants; update their declarations and
every reference (including initialization in the `@PostConstruct` method and any
getter/setter or usage sites) to the new names so the code compiles and retains
the same runtime behavior. Ensure secureRandomThreadLocal remains unchanged if
intended, or rename it consistently if you also want it camelCase.

kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/zkcryptoservice/service/impl/ZKCryptoManagerServiceImpl.java (2)

147-148: ⚡ Quick win

Public static mutable fields expose implementation details.

AES_ECB_ALGO and AES_GCM_ALGO are public static fields initialized in @PostConstruct. They can be read before initialization (returning null) and expose internal algorithm choices externally. Make them private or provide controlled access.

Proposed fix

-    public static String AES_ECB_ALGO;
-    public static String AES_GCM_ALGO;
+    private static String AES_ECB_ALGO;
+    private static String AES_GCM_ALGO;

If external access is needed, provide a getter that validates initialization.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/zkcryptoservice/service/impl/ZKCryptoManagerServiceImpl.java`
around lines 147 - 148, AES_ECB_ALGO and AES_GCM_ALGO are public static mutable
fields and may be read before `@PostConstruct` initialization; make them private
(e.g., private static String AES_ECB_ALGO, AES_GCM_ALGO) and remove public
exposure, then add a controlled accessor (e.g., getAesEcbAlgo() /
getAesGcmAlgo()) that checks initialization and throws or returns a safe default
if null, or lazily initializes from the same `@PostConstruct` logic; update any
usages in ZKCryptoManagerServiceImpl to call these getters instead of accessing
the fields directly.

---

180-190: ⚖️ Poor tradeoff

ThreadLocal cleanup in @PreDestroy won't clear worker thread state.

Same issue as in SignatureServiceImpl: ThreadLocal.remove() only clears the value for the current thread executing the shutdown. Worker threads that processed requests will retain their ThreadLocal values until thread termination.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/zkcryptoservice/service/impl/ZKCryptoManagerServiceImpl.java`
around lines 180 - 190, The shutdown() implementation only calls
ThreadLocal.remove() on the current thread, leaving worker threads' ThreadLocal
state intact; instead, keep shutdown() as a last-resort nulling of the
ThreadLocal references (set CIPHER_AES_ECB = null, CIPHER_AES_GCM = null,
MESSAGE_DIGEST = null) and ensure each place that uses these ThreadLocals
explicitly calls CIPHER_AES_ECB.remove(), CIPHER_AES_GCM.remove(), and
MESSAGE_DIGEST.remove() in a finally block after use (i.e., at the end of
request/worker processing methods that obtain the cipher or digest) so worker
threads clear their state; update shutdown() to null the static ThreadLocal
fields and add per-request finally remove() calls around all usages of the
ThreadLocals.

kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/service/SignatureService.java (1)

80-87: 💤 Low value

Parameter naming is misleading.

The parameter reqCertData is of type Certificate, not certificate data (String). The name and Javadoc suggest it's data, but it's actually a certificate object. Consider renaming for clarity:

Suggested improvement

 	/**
 	 * Validate trust for the given JWT signature verify request.
 	 *
 	 * `@param` jwtVerifyRequestDto the JWTSignatureVerifyRequestDto
-	 * `@param` reqCertData         the certificate data from the request
+	 * `@param` certificateToVerify the certificate to verify trust for
 	 * `@return` a String indicating the validation result
 	 */
-	public String validateTrust(JWTSignatureVerifyRequestDto jwtVerifyRequestDto, Certificate reqCertData);
+	public String validateTrust(JWTSignatureVerifyRequestDto jwtVerifyRequestDto, Certificate certificateToVerify);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/service/SignatureService.java`
around lines 80 - 87, Rename the misleading parameter reqCertData in
SignatureService.validateTrust to something that reflects it's a Certificate
object (e.g., requestCertificate or requestCert), and update the method Javadoc
to describe it as the Certificate object rather than "certificate data"; then
propagate the rename to all implementing classes and callers (implementations of
validateTrust and any places that pass or access that parameter) so signatures
and usages remain consistent.

kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/service/impl/SignatureServiceImpl.java (2)

177-191: 💤 Low value

Static ThreadLocals should have explicit cleanup strategy.

These static ThreadLocal instances (KF_RSA, KF_EC, etc.) will hold references until threads terminate. In servlet containers with thread pools, this can cause memory leaks if the classloader is reloaded (e.g., during hot deployment). Since this is a Spring Boot service typically deployed as a standalone JAR, the risk is lower, but worth documenting.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/service/impl/SignatureServiceImpl.java`
around lines 177 - 191, The static ThreadLocal fields (KF_RSA, KF_EC, KF_ED,
MD_SHA256, B64_DEC, B64_ENC) can leak across thread-pool threads; add an
explicit cleanup hook that calls remove() on each ThreadLocal when the
bean/class is shut down—e.g., implement a lifecycle destroy method (annotated
`@PreDestroy` or implementing DisposableBean) in SignatureServiceImpl that invokes
KF_RSA.remove(), KF_EC.remove(), KF_ED.remove(), MD_SHA256.remove(),
B64_DEC.remove(), and B64_ENC.remove(); alternatively consider making them
non-static or lazily created per-use if bean-scoped lifecycle is preferred.

---

203-215: ⚖️ Poor tradeoff

ThreadLocal cleanup in @PreDestroy is ineffective for request threads.

ThreadLocal.remove() only clears the value for the current thread. During application shutdown, @PreDestroy runs on the main/shutdown thread, not on the HTTP request-handler threads that actually populated these ThreadLocals. The cleanup here won't clear memory held by request threads.

Consider using InheritableThreadLocal with proper cleanup on request completion, or simply document that these are intentionally long-lived for the application lifecycle and rely on thread pool recycling.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/service/impl/SignatureServiceImpl.java`
around lines 203 - 215, The ThreadLocal cleanup in destroy() is ineffective
because ThreadLocal.remove() only clears values on the current (shutdown)
thread; to fix, stop relying on `@PreDestroy` to clear KF_RSA, KF_EC, KF_ED,
MD_SHA256, B64_DEC, B64_ENC (and caches) and instead clear the ThreadLocals at
the end of each request: add a ServletFilter or framework request interceptor
that calls KF_RSA.remove(), KF_EC.remove(), KF_ED.remove(), MD_SHA256.remove(),
B64_DEC.remove(), B64_ENC.remove() in its finally block (and leave destroy() to
clear application-level caches like
jwsHeaderCache/pubKeyCache/certCache/providerCache), or alternatively convert
those ThreadLocals to InheritableThreadLocal with explicit removal in the same
request-finally mechanism and document the lifecycle change so request threads
don’t retain per-request state.

kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/cryptomanager/test/integration/CryptographicServiceIntegrationExceptionTest.java (1)

181-198: 💤 Low value

Error handling behavior changed from 200 OK to 500 Internal Server Error.

The test now expects HTTP 500 instead of 200 OK when decryption fails with invalid input (line 192), and the error code changed from KER-CRY-003 to KER-KMS-500 (line 197). This is a more correct HTTP status for server-side errors, but represents an API behavior change that could affect clients expecting 200 responses with error payloads.

Verify that API consumers can handle the new 500 status code.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/cryptomanager/test/integration/CryptographicServiceIntegrationExceptionTest.java`
around lines 181 - 198, The test testIllegalArgumentException should be updated
to reflect the new API behavior: ensure the mockMvc call to POST "/decrypt"
asserts status().isInternalServerError() and that the parsed ResponseWrapper
error code equals "KER-KMS-500" (use CryptomanagerRequestDto, requestWrapper and
responseWrapper as in the diff); if backward compatibility is required, add a
separate integration test that simulates the legacy behavior and
documents/validates the expected 200-with-error-payload contract for API
consumers instead of changing this test.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 1b379694-7fd5-48dd-bb45-ad9362c20ea1

📥 Commits

Reviewing files that changed from the base of the PR and between 81cf9e8 and 17e7fc4.

📒 Files selected for processing (83)

• README.md
• db_scripts/mosip_keymgr/ddl/keymgr-ca_cert_store.sql
• db_upgrade_scripts/mosip_keymgr/sql/1.2.0.1_to_1.2.1.0_rollback.sql
• db_upgrade_scripts/mosip_keymgr/sql/1.2.0.1_to_1.2.1.0_upgrade.sql
• db_upgrade_scripts/mosip_keymgr/sql/1.2.1.0_to_1.3.0_rollback.sql
• db_upgrade_scripts/mosip_keymgr/sql/1.2.1.0_to_1.3.0_upgrade.sql
• db_upgrade_scripts/mosip_keymgr/sql/1.3.0_to_1.4.0_rollback.sql
• db_upgrade_scripts/mosip_keymgr/sql/1.3.0_to_1.4.0_upgrade.sql
• db_upgrade_scripts/mosip_keymgr/sql/1.4.0_to_1.4.1_rollback.sql
• db_upgrade_scripts/mosip_keymgr/sql/1.4.0_to_1.4.1_upgrade.sql
• db_upgrade_scripts/mosip_keymgr/sql/ca_cert_table_update.sql
• deploy/key-migration-utility/install.sh
• deploy/keymanager/install.sh
• deploy/softhsm/install.sh
• helm/key-migration-utility/Chart.yaml
• helm/key-migration-utility/values.yaml
• helm/keygen/Chart.yaml
• helm/keygen/values.yaml
• helm/keymanager/Chart.yaml
• helm/keymanager/values.yaml
• helm/softhsm/Chart.yaml
• helm/softhsm/values.yaml
• kernel/kernel-keymanager-service/Dockerfile
• kernel/kernel-keymanager-service/configure_start.sh
• kernel/kernel-keymanager-service/pom.xml
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/clientcrypto/service/impl/ClientCryptoFacade.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/clientcrypto/service/impl/LocalClientCryptoServiceImpl.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/crypto/jce/core/CryptoCore.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/cryptomanager/service/impl/CryptomanagerServiceImpl.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/cryptomanager/util/CryptomanagerUtils.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/keymanager/hsm/health/HSMHealthCheck.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/keymanager/hsm/impl/pkcs/PKCS11KeyStoreImpl.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/keymanager/hsm/util/CertificateUtility.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/keymanagerservice/config/ReqResFilter.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/keymanagerservice/config/ResponseBodyAdviceConfig.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/keymanagerservice/exception/InvalidFormatException.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/keymanagerservice/exception/KeymanagerExceptionHandler.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/keymanagerservice/helper/PrivateKeyDecryptorHelper.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/keymanagerservice/helper/SessionKeyDecrytorHelper.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/keymanagerservice/service/KeymanagerService.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/keymanagerservice/service/impl/KeymanagerServiceImpl.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/keymanagerservice/util/KeymanagerUtil.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/keymanagerservice/validator/ECKeyPairGenRequestValidator.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/keymigrate/service/impl/KeyMigratorServiceImpl.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/partnercertservice/constant/PartnerCertManagerConstants.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/partnercertservice/helper/PartnerCertManagerDBHelper.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/partnercertservice/service/impl/PartnerCertificateManagerServiceImpl.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/partnercertservice/util/PartnerCertificateManagerUtil.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/constant/SignatureErrorCode.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/dto/SignResponseDto.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/dto/SignatureResponseDto.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/service/SignatureService.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/service/impl/CoseSignatureServiceImpl.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/service/impl/SignatureServiceImpl.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/signature/util/SignatureUtil.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/tokenidgenerator/generator/TokenIDGenerator.java
• kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/zkcryptoservice/service/impl/ZKCryptoManagerServiceImpl.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/clientcrypto/test/service/AndroidClientCryptoServiceImplTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/crypto/jce/test/CryptoCoreNoSuchAlgorithmExceptionTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/crypto/jce/test/CryptoCoreTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/cryptomanager/test/integration/CryptographicServiceIntegrationExceptionTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/cryptomanager/test/integration/CryptographicServiceIntegrationTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/cryptomanager/test/util/CryptographicUtilExceptionTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/keymanager/hsm/test/PKCS11KeyStoreImplTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/keymanager/hsm/test/health/HSMHealthCheckTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/keymanagerservice/test/service/KeymanagerServiceImplTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/keymanagerservice/test/service/KeymanagerServiceImplUnitTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/keymanagerservice/test/util/KeymanagerUtilTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/keymigrate/test/KeyMigratorControllerTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/keymigrate/test/KeyMigratorServiceTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/partnercertservice/test/controller/PartnerCertManagerControllerTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/partnercertservice/test/service/PartnerCertificateManagerServiceTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/partnercertservice/test/util/PartnerCertificateManagerUtilTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/signature/test/controller/SignatureControllerTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/signature/test/service/CoseSignatureServiceTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/signature/test/service/SignatureServiceTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/signature/test/util/SignatureUtilTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/zkcryptoservice/test/ZKCryptoManagerControlerTest.java
• kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/zkcryptoservice/test/ZKCryptoManagerServiceTest.java
• kernel/keys-generator/pom.xml
• kernel/keys-generator/src/main/java/io/mosip/kernel/keygenerator/generator/RandomKeysGenerator.java
• kernel/keys-migrator/pom.xml
• kernel/pom.xml

💤 Files with no reviewable changes (1)

• db_upgrade_scripts/mosip_keymgr/sql/ca_cert_table_update.sql

[coderabbitai]

⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Don't load an unverified JAR into loader.path at startup.

These lines download kernel-auth-adapter.jar from a runtime URL straight into the loader path that the JVM consumes on startup. That makes the artifact endpoint part of the service's code-execution trust boundary: if the URL or response is tampered with, arbitrary code gets loaded into the process. Please either bake the adapter into the image or verify a pinned checksum/signature before placing it under ${loader_path_env}.

🧰 Tools

🪛 Shellcheck (0.11.0)

[warning] 42-42: iam_adapter_url_env is referenced but not assigned.

(SC2154)

---

[warning] 42-42: loader_path_env is referenced but not assigned.

(SC2154)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@kernel/kernel-keymanager-service/configure_start.sh` around lines 41 - 42,
The script configure_start.sh currently downloads kernel-auth-adapter.jar from
${iam_adapter_url_env} directly into ${loader_path_env}, which introduces an
untrusted code-execution vector; change this by either baking
kernel-auth-adapter.jar into the image instead of downloading at startup, or if
runtime download is required: download to a temporary location, validate against
a pinned checksum or signature (compare computed checksum to a pinned value
provided via an env var or a bundled checksum file, or verify a detached
signature with a trusted GPG key), and only move the JAR into ${loader_path_env}
if verification succeeds; ensure the code path (the download step referencing
iam_adapter_url_env, the temp file, the checksum/signature verification, and the
final mv into loader_path_env) fails the startup with a clear error if
verification fails.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

spring_config_name_env is no longer reaching the JVM.

Line 113 expands $spring_args in the shell created for the CMD, but configure_start.sh only sets spring_args as a local variable before exec "$@". That new shell will not inherit it, so deployments that rely on -Dspring.cloud.config.name=... now start with the wrong config source.

Suggested direction

- CMD java -Dloader.path="${loader_path_env}" -Dspring.cloud.config.label="${spring_config_label_env}" -Dspring.profiles.active="${active_profile_env}" -Dspring.cloud.config.uri="${spring_config_url_env}" $spring_args -jar ./kernel-keymanager-service.jar; \
+ CMD ["/bin/sh", "-c", "exec java -Dloader.path=\"${loader_path_env}\" -Dspring.cloud.config.label=\"${spring_config_label_env}\" -Dspring.profiles.active=\"${active_profile_env}\" -Dspring.cloud.config.uri=\"${spring_config_url_env}\" ${spring_args} -jar ./kernel-keymanager-service.jar"]

Or better, build and exec the full Java command inside configure_start.sh so the optional config-name flag stays in the same shell that computes it.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@kernel/kernel-keymanager-service/Dockerfile` at line 113, The CMD is
expanding $spring_args in a new shell so configure_start.sh's local variable
spring_args (and thus spring_config_name_env) is not propagated; either make
spring_args exported (export spring_args) in configure_start.sh so the spawned
shell inherits it, or preferably assemble the complete java command (including
any -Dspring.cloud.config.name=... from spring_args) inside configure_start.sh
and use exec to replace the shell with that java process (i.e., build the full
command in configure_start.sh and exec it) so the optional config-name flag
remains in the same shell that computes it; update references to spring_args and
ensure configure_start.sh calls exec with the full java command instead of
relying on CMD to expand $spring_args.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical | ⚡ Quick win

Critical: symmetricKeyLength misused as RSA ciphertext byte-length.

symmetricKeyLength (default 256) represents the AES key size in bits, but here it's used as the RSA-encrypted key length in bytes. This works by coincidence because RSA-2048 produces 256-byte ciphertext (2048/8 = 256) and AES-256 has key length 256.

If symmetricKeyLength is changed to 128 (AES-128), decryption will fail by reading only 128 bytes of the 256-byte encrypted key.

🐛 Proposed fix: Use explicit RSA ciphertext length

+    // RSA-2048 produces 256-byte ciphertext (2048 bits / 8)
+    private static final int RSA_ENCRYPTED_KEY_LENGTH = 256;
+
     public byte[] decrypt(byte[] dataToDecrypt) {
         // Extract encrypted AES key and decrypt it
-        byte[] encryptedSecretKey = new byte[symmetricKeyLength];
-        System.arraycopy(dataToDecrypt, 0, encryptedSecretKey, 0, symmetricKeyLength);
+        byte[] encryptedSecretKey = new byte[RSA_ENCRYPTED_KEY_LENGTH];
+        System.arraycopy(dataToDecrypt, 0, encryptedSecretKey, 0, RSA_ENCRYPTED_KEY_LENGTH);
         byte[] secretKeyBytes = Objects.requireNonNull(getClientSecurity()).asymmetricDecrypt(encryptedSecretKey);
         SecretKey secretKey = new SecretKeySpec(secretKeyBytes, "AES");

         // Pre-calculate offsets
-        final int ivOffset = symmetricKeyLength;
+        final int ivOffset = RSA_ENCRYPTED_KEY_LENGTH;

Apply the same change to the fallback block (lines 188-190).

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	byte[] encryptedSecretKey = new byte[symmetricKeyLength];
	System.arraycopy(dataToDecrypt, 0, encryptedSecretKey, 0, symmetricKeyLength);
	byte[] secretKeyBytes = Objects.requireNonNull(getClientSecurity()).asymmetricDecrypt(encryptedSecretKey);
	// RSA-2048 produces 256-byte ciphertext (2048 bits / 8)
	private static final int RSA_ENCRYPTED_KEY_LENGTH = 256;
	public byte[] decrypt(byte[] dataToDecrypt) {
	// Extract encrypted AES key and decrypt it
	byte[] encryptedSecretKey = new byte[RSA_ENCRYPTED_KEY_LENGTH];
	System.arraycopy(dataToDecrypt, 0, encryptedSecretKey, 0, RSA_ENCRYPTED_KEY_LENGTH);
	byte[] secretKeyBytes = Objects.requireNonNull(getClientSecurity()).asymmetricDecrypt(encryptedSecretKey);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/main/java/io/mosip/kernel/clientcrypto/service/impl/ClientCryptoFacade.java`
around lines 161 - 163, In ClientCryptoFacade, stop using symmetricKeyLength as
the RSA-encrypted-key byte length; instead compute the RSA ciphertext length in
bytes from the asymmetric key size (e.g., asymmetricKeySizeBits / 8 or a
provided getAsymmetricKeySizeInBytes() on getClientSecurity()) and use that
value to slice dataToDecrypt into encryptedSecretKey before calling
getClientSecurity().asymmetricDecrypt(encryptedSecretKey); make the same
replacement in the fallback block that currently mirrors lines 188-190 so both
branches use the RSA ciphertext length rather than symmetricKeyLength.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Test documents known buggy behavior instead of correct implementation.

The comment on line 50 states the implementation is "flawed" and "calls encrypt" instead of decrypt. Tests should validate correct behavior, not known bugs. Either:

1. Fix the asymmetricDecrypt implementation to actually decrypt, or
2. If this stub behavior is intentional (e.g., Android placeholder), document why and add a TODO/FIXME with a tracking issue.

Testing buggy behavior can mask regressions when the bug is eventually fixed.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/clientcrypto/test/service/AndroidClientCryptoServiceImplTest.java`
around lines 45 - 53, The test documents and asserts a known-broken behavior in
asymmetricDecrypt; fix by either (A) updating the
AndroidClientCryptoServiceImpl.asymmetricDecrypt implementation to perform real
decryption using the correct private key flow (ensure it uses the counterpart of
getEncryptionPublicPart and proper Cipher/Key handling so asymmetricDecrypt
returns the decrypted bytes), or (B) if the current encrypt-instead-of-decrypt
behavior is an intentional Android stub, update the test
AndroidClientCryptoServiceImplTest to assert the documented stub behavior and
add a TODO/FIXME in AndroidClientCryptoServiceImpl referencing a tracking issue
ID so future fixes won’t be mistaken for regressions (adjust test expectations
and comments accordingly).

[coderabbitai]

⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Test is disabled without explanation.

The testEncrypt test has its @Test annotation commented out (line 131), disabling the test. This reduces coverage and may indicate:

1. The test is flaky or failing
2. The functionality needs refactoring
3. A known issue that should be tracked

Either fix and re-enable the test, or remove it entirely if no longer relevant. If temporary, add a comment explaining why it's disabled and a TODO/tracking issue.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@kernel/kernel-keymanager-service/src/test/java/io/mosip/kernel/cryptomanager/test/integration/CryptographicServiceIntegrationTest.java`
at line 131, The testEncrypt method in CryptographicServiceIntegrationTest has
its `@Test` annotation commented out; either re-enable the test by restoring the
`@Test` annotation on testEncrypt and fix any underlying failures (investigate and
resolve flakiness or assertion errors in testEncrypt), or remove the test
entirely if it is no longer relevant; if you must keep it disabled temporarily,
leave the annotation commented and add a clear one-line comment above
testEncrypt explaining why it is disabled plus a TODO with a tracking issue/ID
so it can be revisited (reference: class CryptographicServiceIntegrationTest and
method testEncrypt).

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

How does Maven handle duplicate property declarations and duplicate plugin declarations in the same POM, and does Maven 4 fail builds for duplicate plugin definitions?

💡 Result:

Maven duplicate property declarations (same property key in the same effective model) - Maven’s model building/merging uses a Properties merge step where keys are combined into a single java.util.Properties map; the later put for the same key overwrites the prior value. The ModelMerger implementation shows it merges by calling merged.putAll(...) for both target and source depending on sourceDominant; because Properties is a map, if both contain the same key, the later putAll overwrites the earlier value [1][2]. - So, within a single POM’s effective model after merging, duplicate property keys resolve by “last write wins” semantics for the key. Maven duplicate plugin declarations (same groupId+artifactId in the same POM) - Maven treats the effective model’s list of build plugins as requiring uniqueness for the key (groupId:artifactId). When duplicates are present, Maven emits a warning: “'build.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin …”. Maven’s guidance is that future Maven versions might no longer support malformed projects [3][4]. - The duplicates are not merged purely “XML-wise”; instead Maven logs the uniqueness violation and (in practice) merges usages’ executions. For example, an Apache HBase change notes that two usages of the build-helper-maven-plugin were present and that “Merged the executions of two usages of the build-helper-maven-plugin” [4]. Does Maven 4 fail builds for duplicate plugin definitions? - The sources found show Maven 4 issues around other “duplicate key”/merge problems (e.g., MNG-8418 discusses Maven 4 failing due to a “Duplicate key default” merge in Activation) [5], but they do not show Maven 4 specifically failing the build merely because a POM contains duplicate plugin declarations of the same groupId:artifactId. - What we do have for duplicate plugins is: Maven currently warns and recommends fixing; it also states that future Maven versions might not build malformed projects [3][4]. There is no evidence in the searched sources that Maven 4 unconditionally fails builds for duplicate plugin definitions. Best practical takeaway - For duplicate properties: treat duplicate keys as last-wins because model merging ultimately overwrites map values on key collision [1][2]. - For duplicate plugins: remove the duplicate plugin declarations or consolidate into a single entry (keep multiple blocks with distinct ids if needed) to avoid unstable/undefined behavior; Maven currently warns on duplicates [3][4]. - For Maven 4: based on evidence found, don’t assume it always fails—expect warnings for duplicate plugin declarations, but it may fail for other duplicate/merge collisions that trigger hard errors (example: Activation “Duplicate key default”) [5].

Citations:

• 1: https://maven.apache.org/ref/3.8.8/xref/org/apache/maven/model/merge/ModelMerger.html
• 2: https://maven.apache.org/ref/3.8.4/maven-model/xref/org/apache/maven/model/merge/ModelMerger.html
• 3: Duplicate declaration of plugin maven-dependency-plugin in dspace/modules/server/pom.xml DSpace/DSpace#9942
• 4: HBASE-29162 Fix Maven build warnings apache/hbase#6748
• 5: https://issues.apache.org/jira/browse/MNG-8418?focusedCommentId=17910335&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

FILE="kernel/keys-generator/pom.xml"

echo "== File exists? =="
test -f "$FILE" && echo "Found $FILE" || { echo "Missing $FILE"; exit 1; }

echo "== Lines 1-80 =="
nl -ba "$FILE" | sed -n '1,120p'

echo "== Lines 120-220 =="
nl -ba "$FILE" | sed -n '120,260p'

echo "== Counts / locations =="
rg -n "central\.publishing\.maven\.plugin\.version" "$FILE" || true
rg -n "<artifactId>maven-deploy-plugin</artifactId>" "$FILE" || true
rg -n "<artifactId>central-publishing-maven-plugin</artifactId>" "$FILE" || true
rg -n "org\.postgresql:postgresql" "$FILE" || true

Repository: mosip/keymanager

Length of output: 194

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

FILE="kernel/keys-generator/pom.xml"

test -f "$FILE"

echo "== Lines 1-120 =="
awk 'NR>=1 && NR<=120 {printf "%d:%s\n", NR, $0}' "$FILE"

echo "== Lines 120-260 =="
awk 'NR>=120 && NR<=260 {printf "%d:%s\n", NR, $0}' "$FILE"

echo "== Counts / locations =="
rg -n "central\.publishing\.maven\.plugin\.version" "$FILE" || true
rg -n "<artifactId>maven-deploy-plugin</artifactId>" "$FILE" || true
rg -n "<artifactId>central-publishing-maven-plugin</artifactId>" "$FILE" || true
rg -n "org\.postgresql:postgresql" "$FILE" || true

Repository: mosip/keymanager

Length of output: 9705

---

🌐 Web query:

GHSA-98qh-xjc8-98pq affected versions org.postgresql postgresql 42.7.3

💡 Result:

The vulnerability GHSA-98qh-xjc8-98pq, also identified as CVE-2026-42198, affects the PostgreSQL JDBC Driver (pgjdbc) [1][2]. The vulnerability involves unbounded PBKDF2 iterations during SCRAM-SHA-256 authentication, which can lead to a client-side denial of service (DoS) due to CPU exhaustion [2]. Affected versions include all versions of the pgjdbc driver from 42.2.0 up to, but not including, 42.7.11 [1][2]. As version 42.7.3 falls within this range (>=42.2.0 and <42.7.11), it is considered an affected version [3][1]. The issue was patched in version 42.7.11 [1][2].

Citations:

• 1: GHSA-98qh-xjc8-98pq
• 2: https://nvd.nist.gov/vuln/detail/CVE-2026-42198
• 3: https://osv.dev/vulnerability/GHSA-98qh-xjc8-98pq

---

Fix duplicate Maven declarations and upgrade vulnerable PostgreSQL JDBC driver

• kernel/keys-generator/pom.xml declares central.publishing.maven.plugin.version twice (lines 21-22) and repeats maven-deploy-plugin and org.sonatype.central:central-publishing-maven-plugin twice in the build plugins section (lines 138-183). Consolidate each to a single declaration to avoid an ambiguous/malformed effective model (Maven emits duplicate-plugin-model warnings and future Maven may be stricter).
• org.postgresql:postgresql is pinned to 42.7.3 (via ${postgresql.version}) which is in the GHSA-98qh-xjc8-98pq affected range (patched in 42.7.11), so upgrade to >= 42.7.11.

Minimal cleanup

-        <central.publishing.maven.plugin.version>0.7.0</central.publishing.maven.plugin.version>
         <central.publishing.maven.plugin.version>0.7.0</central.publishing.maven.plugin.version>
@@
-            <plugin>
-              <artifactId>maven-deploy-plugin</artifactId>
-              <version>2.8.1</version>
-              <executions>
-                 <execution>
-                    <id>default-deploy</id>
-                    <phase>deploy</phase>
-                    <goals>
-                       <goal>deploy</goal>
-                    </goals>
-                 </execution>
-              </executions>
-           </plugin>
             <plugin>
                 <groupId>org.sonatype.central</groupId>
                 <artifactId>central-publishing-maven-plugin</artifactId>
                 <version>${central.publishing.maven.plugin.version}</version>
                 <extensions>true</extensions>
                 <configuration>
                     <publishingServerId>ossrh</publishingServerId>
                     <autoPublish>false</autoPublish>
                 </configuration>
             </plugin>
-            <plugin>
-                <groupId>org.sonatype.central</groupId>
-                <artifactId>central-publishing-maven-plugin</artifactId>
-                <version>${central.publishing.maven.plugin.version}</version>
-                <extensions>true</extensions>
-                <configuration>
-                    <publishingServerId>ossrh</publishingServerId>
-                    <autoPublish>false</autoPublish>
-                </configuration>
-            </plugin>
             <plugin>
                 <artifactId>maven-deploy-plugin</artifactId>
                 <version>2.8.1</version>

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@kernel/keys-generator/pom.xml` around lines 21 - 22, Remove the duplicate
property and duplicate plugin blocks: keep a single
<central.publishing.maven.plugin.version> declaration (remove the repeated one)
and consolidate the repeated maven-deploy-plugin and
org.sonatype.central:central-publishing-maven-plugin entries in the
build/plugins section so each plugin appears only once (edit the pom entries
referencing central.publishing.maven.plugin.version, maven-deploy-plugin, and
org.sonatype.central:central-publishing-maven-plugin). Also bump the PostgreSQL
driver by updating the ${postgresql.version} property (and any direct
org.postgresql:postgresql version entries) to 42.7.11 or newer to address
GHSA-98qh-xjc8-98pq.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

What is the first org.postgresql:postgresql version that fixes GHSA-98qh-xjc8-98pq, and is version 42.7.3 affected?

💡 Result:

The first version of the org.postgresql:postgresql JDBC driver that fixes GHSA-98qh-xjc8-98pq is 42.7.11 [1][2][3]. Yes, version 42.7.3 is affected by this vulnerability [4][5][3]. The vulnerability affects all versions of the pgjdbc driver from 42.2.0 up to, but not including, version 42.7.11 [1][2][3]. This issue (CVE-2026-42198) involves a client-side denial of service vulnerability where a malicious PostgreSQL server can cause the driver to perform an unbounded number of PBKDF2 iterations during SCRAM-SHA-256 authentication, leading to CPU exhaustion [1][2][3].

Citations:

• 1: GHSA-98qh-xjc8-98pq
• 2: https://nvd.nist.gov/vuln/detail/CVE-2026-42198
• 3: https://app.opencve.io/cve/CVE-2026-42198
• 4: https://osv.dev/vulnerability/GHSA-98qh-xjc8-98pq
• 5: https://app-catalog.vmware.com/bitnami/apps/33ff5603-01b2-4310-a541-0d24b516cb56/pipelines/2a6be2fb-f505-4779-b053-9c35c4c6d86a/vulnerabilities/851724

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Show the relevant pom section around the referenced line
sed -n '1,120p' kernel/keys-generator/pom.xml | nl -ba | sed -n '1,120p'

# Confirm the property definition
rg -n "postgresql\.version|org\.postgresql:postgresql|<postgresql\.version>" kernel/keys-generator/pom.xml || true

# Find all uses of the property in this module
rg -n "<postgresql\.version>|postgresql\.version" kernel/keys-generator/pom.xml

# Search the whole repo for other definitions/usages of 42.7.3 (limited output)
rg -n "org\.postgresql:postgresql|<postgresql\.version>\s*42\.7\.3" . || true

Repository: mosip/keymanager

Length of output: 103

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Print first ~120 lines with line numbers (no nl available)
sed -n '1,120p' kernel/keys-generator/pom.xml | awk '{printf "%4d\t%s\n", NR, $0}' | sed -n '25,60p'

# Confirm the property definition and any org.postgresql:postgresql usage in this module
rg -n "postgresql\.version|org\.postgresql:postgresql|<postgresql\.version>" kernel/keys-generator/pom.xml || true
rg -n "<postgresql\.version>|postgresql\.version" kernel/keys-generator/pom.xml || true

Repository: mosip/keymanager

Length of output: 1609

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Inspect around the dependency that uses ${postgresql.version}
sed -n '55,95p' kernel/keys-generator/pom.xml | awk '{printf "%4d\t%s\n", NR+54, $0}'

# Find all property overrides/usages in the repo
rg -n "<postgresql\.version>|org\.postgresql:postgresql" . || true

# Count where 42.7.3 appears
rg -n "42\.7\.3" . || true

Repository: mosip/keymanager

Length of output: 2218

---

Upgrade org.postgresql:postgresql from 42.7.3 to 42.7.11+ before release.

		<postgresql.version>42.7.3</postgresql.version>

• GHSA-98qh-xjc8-98pq is fixed in org.postgresql:postgresql 42.7.11; versions <42.7.11 (including 42.7.3) are affected.
• kernel/keys-generator/pom.xml sets postgresql.version to 42.7.3 and uses it for the org.postgresql:postgresql dependency; the same 42.7.3 property is also present in kernel/keys-migrator/pom.xml and kernel/kernel-keymanager-service/pom.xml.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@kernel/keys-generator/pom.xml` at line 31, Update the Maven property
postgresql.version from 42.7.3 to at least 42.7.11 and ensure the
org.postgresql:postgresql dependency across the affected modules
(keys-generator, keys-migrator, kernel-keymanager-service) uses the updated
property; change the postgresql.version property entry in each module's pom to
42.7.11 (or newer), then rebuild to confirm the new transient dependency is
picked up.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Typo in SCM connection URL.

The URL contains keyanager instead of keymanager. This will cause SCM operations to fail.

Proposed fix

-		<connection>scm:git:git://github.com/mosip/keyanager.git</connection>
+		<connection>scm:git:git://github.com/mosip/keymanager.git</connection>

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	<connection>scm:git:git://github.com/mosip/keyanager.git</connection>
	<connection>scm:git:git://github.com/mosip/keymanager.git</connection>

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@kernel/keys-migrator/pom.xml` at line 242, Fix the typo in the SCM connection
element: replace the current connection value
"scm:git:git://github.com/mosip/keyanager.git" with the correct repository name
"scm:git:git://github.com/mosip/keymanager.git" so the <connection> element
points to the valid repo (update the value in the existing <connection> tag
within the POM).