Summary of Changes

Hello @sixcolors, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the robustness of the UUID generation mechanism by implementing a fail-fast approach during its initialization. Instead of silently failing or providing a default, potentially invalid, UUID, the system will now panic if critical steps like seeding the random number generator or initializing the counter encounter errors. This ensures that any issues with UUID setup are immediately apparent, preventing the propagation of invalid UUIDs throughout the application.

Highlights

• Error Handling: The UUID generation function now panics instead of silently failing or returning a default UUID when initialization errors occur.
• UUID Seeding: Proper error handling has been introduced for seeding the UUID generator using crypto/rand, causing a panic on failure.
• Counter Initialization: A check for proper uuidCounter initialization now results in a panic if the counter is not set up correctly, replacing the previous behavior of returning a default UUID string.

We should return an error, not panic(). Let the caller handle the error and determine the fallback themselves.

Why is this needed? I believe crypto/rand already panics and never returns a non-nil error? (ref: golang/go#66821 & https://cs.opensource.google/go/go/+/refs/tags/go1.25.5:src/crypto/rand/rand.go;l=80

Why is this needed? I believe crypto/rand already panics and never returns a non-nil error? (ref: golang/go#66821 & https://cs.opensource.google/go/go/+/refs/tags/go1.25.5:src/crypto/rand/rand.go;l=80

@kalafut thanks for pointing this out. You are correct thatcrypto/rand guarantees panic-on-failure beginning in Go 1.24. However, note target branch is v1.

Even the master branch of github.com/gofiber/utils/v2 explicitly sets go 1.23.0 in its go.mod

We should return an error, not panic(). Let the caller handle the error and determine the fallback themselves.

This is a backport of the security advisory change for utils v1: GHSA‑m98w‑cqp3‑qcqr.

We cannot return an error without changing the function signature, which guarantees a string return. Since UUID() is used for security-critical identifiers (tokens, session IDs, etc.), a failure in crypto/rand must be fatal — returning a zero or predictable UUID would be a critical vulnerability. The Go team’s guidance is the same: RNG failures are unrecoverable and should terminate execution.

The panics here are intentional and correct. While crypto/rand failures pre‑Go 1.24 are extremely rare on modern hosts, the real issue was that utils previously ignored failures and returned the all-zero UUID. Failing fast ensures the process exits so the orchestrator (systemd, Kubernetes, Nomad, Docker Swarm, etc.) can restart or reschedule the service. If the host’s CSPRNG is genuinely broken, the service will crash again — exactly what we want, because it signals an unhealthy node and prevents insecure behaviour.