OpenDAL releases are now safer with trusted publishing 🎉

[Xuanwo]

Great news: we have completed a major cleanup of OpenDAL’s GitHub Actions credentials and moved our supported package release workflows to trusted publishing.

This is more than routine maintenance. It is an important step toward making OpenDAL’s release process safer, simpler, and easier to audit.

What changed?

OpenDAL now keeps only three repository-level Actions secrets:

• GPG_SECRET_KEY, used to sign Java artifacts published through Apache Nexus.
• OP_CONNECT_HOST and OP_CONNECT_TOKEN, used to load behavior-test credentials from 1Password.

The rust-bootstrap environment contains one additional, tightly scoped secret:

• CARGO_REGISTRY_BOOTSTRAP_TOKEN, used only by a maintainer-triggered workflow when bootstrapping newly introduced crates.io packages. Normal Rust releases never use this token.

All legacy per-service test secrets and obsolete registry tokens have been removed. Backend test credentials are now managed centrally through 1Password.

Trusted publishing by default

The normal release paths for the following ecosystems now use short-lived OIDC credentials instead of long-lived registry tokens stored in GitHub:

• Rust packages published to crates.io.
• Python packages published to PyPI and TestPyPI.
• Node.js packages published to npm.
• .NET packages published to NuGet.
• Ruby packages published to RubyGems.

Java remains on the ASF Nexus release path with ASF-managed Maven credentials and GPG signing. The Dart workflow currently builds release artifacts but does not publish to pub.dev.

Why does this matter?

Long-lived publishing tokens increase the impact of accidental disclosure and require ongoing storage, rotation, and access management.

Trusted publishing changes that model:

• Credentials are issued only when an authorized release workflow runs.
• Credentials are short-lived and bound to the expected repository, workflow, and environment.
• A leaked GitHub secret can no longer become a permanent package-publishing credential.
• Maintainers have fewer credentials to rotate, distribute, and audit.
• The release configuration becomes easier to understand and safer to evolve.

This cleanup substantially reduces OpenDAL’s credential footprint and limits the blast radius of the remaining secrets.

It is a meaningful security and release-engineering milestone for the project. Thank you to everyone who helped make it happen! 🚀

[github-actions[bot]]

Mailing list thread: https://lists.apache.org/thread/hn24yfclg78d010vyh6n250cslzq9gmg

[erickguan]

Congrats! This is the important step to build reliable attestation for OpenDAL and dependents.