Migrate file upload digest algorithm from MD5 to SHA-384 (FIPS 140-3 + NCS)

[vkalapov]

What

Change Constants.DIGEST_ALGORITHM from "MD5" to "SHA-384" and update all test fixtures accordingly.

Why

SHA-384 satisfies both FIPS 140-3 (FIPS 180-4) and NCS MODERATE requirements. MD5 and SHA-256 are not approved at NCS MODERATE level.

Compatibility

Backward compatible — no breaking change.

The server always computes and stores its own digest on upload (DatabaseFileService → SqlFileQueryProvider). No client-sent digest is ever read or verified on the server side.

• Old CLI users: isFileAlreadyUploaded will hit "Unsupported digest algorithm" for the SHA-384 entries returned by GET /files, re-upload on every retry instead of skipping — deploys complete successfully.
• First deploy after DS restart: UploadAppStep detects mismatch between freshly computed SHA-384 and the MD5 value stored in the CF app environment → one-time forced re-upload of every app binary. Self-heals on the second deploy.

LMCROSSITXSADEPLOY-3224

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[theghost5800]

Why sha256 digest was used instead of sha-384?

[theghost5800]

Shouldn't we use SHA3 alrogirthm instead of SHA2? Also recommended length isn't it 512 instead of 384?

Another important thing is what will happen when this change is applied during blue-green update and there are running mta operations or files upload?

What will happen if files were uploaded and persisted with md5 digest and then read/retrieved from updated instance of deploy service and try to parse stored md5 checksums as SHA-384? I think we have to implement some backwards compatible logic in order to avoid breaking running mta operations/running file uploads.