Skip to content

Add SHA-384 support to file checksum computation (FIPS+NCS) - #267

Open
vkalapov wants to merge 1 commit into
masterfrom
fips-file-digest-sha256
Open

Add SHA-384 support to file checksum computation (FIPS+NCS)#267
vkalapov wants to merge 1 commit into
masterfrom
fips-file-digest-sha256

Conversation

@vkalapov

Copy link
Copy Markdown
Contributor

What

Add SHA384 / SHA-384 cases to ComputeFileChecksum in util/digest.go, and also handle the hyphenated SHA-256 variant while here.

Why

The deploy service now stores file digests with SHA-384 (DIGEST_ALGORITHM = "SHA-384") to satisfy FIPS 140-3 and NCS MODERATE requirements. The CLI calls GET /files and uses the digestAlgorithm field returned per entry to compute a local digest for skip-upload optimisation. Without this change, old CLI hits the default branch and prints "Unsupported digest algorithm \"SHA-384\"", causing a re-upload on every retry instead of skipping.

Deploys still succeed without this fix (the server never verifies a client-sent digest), but the skip optimisation is degraded.

LMCROSSITXSADEPLOY-3224

@vkalapov
vkalapov force-pushed the fips-file-digest-sha256 branch from ec08ad6 to 505e9f1 Compare July 28, 2026 08:43
Comment thread util/digest.go
hasher = sha1.New()
case "SHA256":
hasher = sha256.New()
case "SHA384", "SHA-384":

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we add support for sha3 algorithms?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SHA3 is needed for advanced requirements, SHA-384 satisfies the moderate requirements in our case.

Comment thread util/digest.go
@@ -23,6 +23,8 @@ func ComputeFileChecksum(filePath, algorithm string) (string, error) {
hasher = sha1.New()
case "SHA256":

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the current plugin, without these changes compatible with the response from the deploy-service as it returns the algorithm?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the current plugin with the backend changes finishes deployments successfully. However, if a SHA-384 file entry already exists from a previous deploy (e.g. an orphan from an interrupted deploy), the old plugin prints a FAILED message because it doesn't know SHA-384, and continues the deployment after re-uploading the file. The deploy completes normally, but the orphaned file entry remains until a periodic cleanup job removes it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants