Skip to content

fix: enforce single expiration timestamp per storage credential bundle#4226

Closed
yushesp wants to merge 1 commit into
apache:mainfrom
yushesp:fix/expire-storage-credentials
Closed

fix: enforce single expiration timestamp per storage credential bundle#4226
yushesp wants to merge 1 commit into
apache:mainfrom
yushesp:fix/expire-storage-credentials

Conversation

@yushesp
Copy link
Copy Markdown
Contributor

@yushesp yushesp commented Apr 16, 2026

StorageAccessConfig.Builder.put() silently overwrites expiresAt when multiple expiration timestamp properties are set. Only a single expiration timestamp is valid per credential bundle. Multiple timestamps indicate incorrect behavior that should fail fast rather than silently picking one.

This mirrors the same fix applied to ConnectionCredentials.of() in #4173.

Also fixes AwsCredentialsStorageIntegration which was the only production caller setting two expiration timestamps (EXPIRATION_TIME and AWS_SESSION_TOKEN_EXPIRES_AT_MS).

Checklist

  • 🛡️ Don't disclose security issues! (contact security@apache.org)
  • 🔗 Clearly explained why the changes are needed, or linked related issues: Fixes #
  • 🧪 Added/updated tests with good coverage, or manually tested (and explained how)
  • 💡 Added comments for complex logic
  • 🧾 Updated CHANGELOG.md (if needed)
  • 📚 Updated documentation in site/content/in-dev/unreleased (if needed)

StorageAccessConfig.Builder.put() silently overwrites expiresAt when
multiple expiration timestamp properties are set. Only a single expiration
timestamp is valid per credential bundle. Multiple timestamps indicate
incorrect behavior that should fail fast rather than silently picking one.
This mirrors the same fix applied to ConnectionCredentials.of() in apache#4173.

Also fixes AwsCredentialsStorageIntegration which was the only production
caller setting two expiration timestamps (EXPIRATION_TIME and
AWS_SESSION_TOKEN_EXPIRES_AT_MS) via put().
@yushesp
Copy link
Copy Markdown
Contributor Author

yushesp commented Apr 16, 2026

hey @dimas-b and @flyrain, put together a similar change for StorageAccessConfig as suggested in #4173. It was a bit more involved due to the "builder" pattern used here, open to a different approach if needed!

Copy link
Copy Markdown
Contributor

@dimas-b dimas-b left a comment

Choose a reason for hiding this comment

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

Thanks for working on this, @yushesp ! The PR LGTM overall, some comment below, and I believe we also need a dev ML discussion because it involves configuration sent to REST API clients.

* calls to {@link Builder#put} with different expiration timestamp properties silently overwrite
* {@link StorageAccessConfig#expiresAt()}.
*/
class ValidatingBuilder implements Builder {
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.


assertThat(
StorageAccessConfig.builder()
.put(GCS_ACCESS_TOKEN_EXPIRES_AT, "111")
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.

Maybe use @ParameterizedTest and also add coverage for AZURE_SAS_TOKEN_EXPIRES_AT_MS_PREFIX?

.ifPresent(
i -> {
accessConfig.put(
StorageAccessProperty.EXPIRATION_TIME, String.valueOf(i.toEpochMilli()));
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 EXPIRATION_TIME property used anymore? Let's deprecate it.

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.

Please also mention it in CHANGELOG that we're no longer emitting this property.

AFAIK, it is not used by clients, but let's also discuss this on dev to double check.

@github-actions
Copy link
Copy Markdown

ghost commented May 18, 2026

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

@github-project-automation github-project-automation Bot moved this from PRs In Progress to Done in Basic Kanban Board May 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants