Ability to disable non default signature algorithm(s)#5
Open
bobhageman wants to merge 44 commits into
Open
Conversation
Ability to disable non default signature algorithm
bwesterb
reviewed
Nov 3, 2023
| # are disabled. This is useful if you only want to support one algorithm. | ||
| # NOTE: if true, you can still verify validity of timestamps generated with | ||
| # any other supported algorithm for the keys listed in otherTrustedPublicKeys | ||
| disableOtherSigAlg: false |
Owner
There was a problem hiding this comment.
This presumes that either there only will be two signature algorithms supported or that you'd only want to enable one of them. It seems more logical to me to have an option enabledSigAlgs, and then perhaps interpret the first as the default.
Why do you want to disable one of them btw?
Author
There was a problem hiding this comment.
Currently Yivi is creating a PoC moving the infrastructure into a cloud agnostic environment. Since we are only using ed25519 and we need atumd to be stateless, this small change is (for us) the least intrusive way to make that happen. No change in config needed to keep the current situation running while it is possible to disable all other algorithms (for now only XMSS[MT]) except the default one in our cloud setup.
Thought this could be a nice addition in functionality, hence the pr. On the other hand I also agree with you that the other way around with an option like enabledSigAlgs would be a nice approach.
…k-on-Ed25519KeyPath relax file permission check on Ed25519KeyPath
…k-on-Ed25519KeyPath fileInfo declared and not used
Liveness check added
This reverts commit d927edb.
chore: Update dependencies
fix: Scan image and unify image tagging
- Bump Go directive to 1.25.0 and toolchain to go1.25.10 (clears 19 stdlib advisories reported by govulncheck against the prior go1.24.0 toolchain). - Refresh direct deps: go-chi/cors 1.2.2, prometheus/client_golang 1.23.2, golang.org/x/crypto 0.51.0. - Refresh indirect deps via go mod tidy. Verified with govulncheck ./... (no vulnerabilities found) and go build ./....
Add a smoke test for the timestamping endpoint (POST /) that wires up minimal globals with Ed25519 only, exercises rootHandler via httptest, and verifies the returned signature. Add a `test` job to the delivery workflow running `go test ./...` and make `publish-docker-image` depend on it via `needs: test`.
actions/checkout@v4 and actions/setup-go@v5 still run on Node.js 20, which GitHub switches to Node.js 24 by default on 2026-06-02 and removes from runners on 2026-09-16. v6 of both actions ships on Node 24.
- docker/metadata-action v5 -> v6
- docker/setup-buildx-action v3 -> v4
- docker/login-action v3 -> v4
- docker/build-push-action v5 -> v7 (build + push steps)
- anchore/scan-action v3 -> v7 (fixes stale grype + v5 vuln DB
retirement causing "db built 10
weeks ago" scan failures)
- github/codeql-action/upload-sarif v3 -> v4
actions/checkout and actions/setup-go were already bumped to v6 in the
previous commit. All actions now run on Node.js 24.
chore: update dependencies
- Cap request body via http.MaxBytesReader (4 KiB) and return 413 on overflow. - Replace bare http.ListenAndServe with explicit http.Server carrying ReadHeaderTimeout / ReadTimeout / WriteTimeout / IdleTimeout. - Fix XMSSMTBorrowedSeqNos struct tag: taml -> yaml. The config setting was silently ignored before. - healthCheckHandler: set Content-Type before WriteHeader so the header actually applies.
- TestRequestBodyLimit: posts an 8 KiB body and asserts 413 — exercises the new MaxBytesReader rejection path. - TestHealthCheckContentType: asserts Content-Type is text/plain — regresses the WriteHeader/Header ordering bug fixed in the same PR. - TestXMSSMTBorrowedSeqNosYAMLTag: yaml.Unmarshals a config snippet and asserts the field is populated — regresses the taml -> yaml struct tag typo that silently dropped this config key.
computePowNonces mutated serverInfo.RequiredProofOfWork in place under the lock, but getServerInfo hands callers a struct copy that shares that map and handlers read it without the lock — a concurrent map read/write that the race detector flags and that can crash the process with "fatal error: concurrent map read and map write". Build the map fresh and publish it by replacing the reference under the lock so readers always see an immutable snapshot. processAtumRequest logged but swallowed errors from CreateXMSSMTTimestamp, leaving resp.Stamp nil and then dereferencing it at resp.Stamp.ServerUrl. Return an error response to the client instead. Add a -race regression test for the serverInfo map access. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The Delivery pipeline's "Scan Image" (Anchore/Grype, --fail-on critical) step failed: the built image (scratch + static Go binary) carried 7 critical advisories from golang.org/x/crypto v0.51.0, all fixed in v0.52.0 (GO-2026-5005/5006/5017/5019/5020/5021/5023). - Bump golang.org/x/crypto v0.51.0 -> v0.52.0 (pulls golang.org/x/sys v0.44.0 -> v0.45.0). x/crypto is a direct import (ed25519, sha3). - Bump toolchain go1.25.10 -> go1.25.11 to clear the remaining High stdlib advisories (CVE-2026-42504, GO-2026-5038); below the critical gate but makes the published image vulnerability-clean. Verified locally: go build, go vet, go test -race ./... all pass, and grype --fail-on critical --only-fixed reports no vulnerabilities on the rebuilt static binary. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…mssmt-niljdrf fix: serverInfo map data race and XMSSMT nil-deref
# Conflicts: # main_test.go
chore: harden HTTP server (body limit, timeouts, config-tag typo)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This modification adds an extra boolean configuration variable
disableOtherSigAlgthat allows you to disable all signature algorithms other than the specifieddefaultSigAlg.If for example
defaultSigAlgis set toed25519anddisableOtherSigAlg=trueit will not be possible to generate a timestamp based on XMSS[MT]. Also (automatic) XMSS[MT] key generation at startup will not happen in this case, essentially disabling all XMSS[MT] based functionality.There is one exception: it will always be possible to verify timestamps for all supported algorithms. So in a scenario where XMSS[MT] is used as algorithm and server config is changed to only accept Ed25519 from now on, it is still possible to validate XMSS[MT] timestamps as long as the public key is listed in
otherTrustedPublicKeys.