v3.1.8 - security patch

What's Changed

• Enable latest check for govulncheck workflow by @briskt in #70
• Bump Caddy to v2.11.4 to resolve govulncheck scan failure by @briskt with @Copilot in #71

New Contributors

• @briskt with @Copilot made their first contribution in #71

Full Changelog: v3.1.7...v3.1.8

v3.1.7 - security patch

What's Changed

• update Go to 1.25.11 to address security issue by @briskt in #68

Full Changelog: v3.1.6...v3.1.7

v3.1.6 - security patch

What's Changed

• bump golang.org/x/net to v0.55.0 by @briskt in #66

Full Changelog: v3.1.5...v3.1.6

v3.1.5 - security patches

What's Changed

• upgrade GitHub actions by @briskt in #62
• add scheduled govulncheck workflow by @briskt in #63
• Bump github.com/caddyserver/caddy/v2 from 2.11.1 to 2.11.3 by @dependabot[bot] in #64
• update to Go 1.25.10 to include security patches by @briskt in #65

Full Changelog: v3.1.4...v3.1.5

v3.1.4 - security update

What's Changed

• update dependencies, primarily for CVE-2025-64702 by @briskt in #61

Full Changelog: v3.1.3...v3.1.4

v3.1.3 - Go update and bump golang.org/x/crypto

What's Changed

• update to Go 1.25 by @briskt in #57
• Bump golang.org/x/crypto from 0.36.0 to 0.45.0 by @dependabot[bot] in #58

Full Changelog: v3.1.2...v3.1.3

v3.1.2

What's Changed

• Rename docker-compose.yml to compose.yaml by @briskt in #55
• Bump github.com/quic-go/quic-go from 0.48.2 to 0.49.1 by @dependabot[bot] in #56

Full Changelog: v3.1.1...v3.1.2

v3.1.1

What's Changed

• Bump golang.org/x/net from 0.36.0 to 0.38.0 by @dependabot in #53

Full Changelog: v3.1.0...v3.1.1

v3.1.0 -- enhance locking, security patch

What's Changed

• Enhance locking with atomic acquisition and refresh by @hrko in #51
• Bump golang.org/x/net from 0.33.0 to 0.36.0 by @dependabot in #52

New Contributors

• @hrko made their first contribution in #51

Full Changelog: v3.0.11...v3.1.0

v3.1.0-pre.0

Overview

This PR introduces crucial changes to enhance the reliability and robustness of the locking mechanism. Specifically, it adds the functionality to make lock acquisition atomic and to periodically refresh the lock's expiration time. These changes reduce the risk of race conditions in concurrent environments, leading to more stable certificate management.

Key Changes

1. Atomic Lock Acquisition Logic:

• In the previous implementation, checking for lock existence and creating the lock were separate steps, which could allow another process to acquire the lock in between.
• The new implementation uses DynamoDB's PutItem operation with a ConditionExpression to make lock existence check and creation atomic.
• By combining the attribute_not_exists and ExpiresAt conditions, the lock is only acquired if it does not exist or if it exists but has expired.
• Furthermore, each lock is assigned a unique UUID (LockID), and the UpdateItem operation's ConditionExpression checks the LockID to ensure that only the lock created by itself can be updated.

2. Periodic Lock Expiration Refresh:

• The previous implementation had a fixed lock expiration time, which could lead to the lock expiring if the critical section took too long.
• The new implementation starts a goroutine within the Lock method to periodically refresh the lock's expiration time at LockRefreshInterval (defaulting to LockTimeout / 3).
• This ensures that the lock is held until the critical section's process is complete.

Problems Solved and Benefits of the Changes

• Race Condition Prevention: Atomic lock acquisition prevents race conditions where multiple processes attempt to acquire the lock simultaneously.
• Critical Section Protection: Periodic lock refreshes prevent other instances from entering the critical section at the same time due to the lock expiring during the execution of the critical section. This prevents situations like:
  1. An instance acquires the lock and enters the critical section.
  2. The critical section's processing takes a long time, and the lock expires.
  3. Another instance acquires the lock and enters the critical section simultaneously.
  4. As a result, unexpected behavior occurs (for example, the certificate issuance process in the instance that first acquired the lock may stall).
• Improved Reliability: A more robust locking mechanism improves the reliability of certificate acquisition and renewal processes.
• Improved Stability in Clustered Environments: More stable behavior is expected, especially in clustered environments where multiple application instances share DynamoDB.

What's Changed

• Enhance locking with atomic acquisition and refresh by @hrko in #51

New Contributors

• @hrko made their first contribution in #51

Full Changelog: v3.0.11...v3.1.0-pre.0