Create a trusted-publish credential provider plugin

[ojuschugh1]

What does this PR try to resolve?

This PR implements a trusted-publish credential provider plugin to solve the security issue described in #15743.

Problem

Currently, when using cargo publish with trusted publishing, the temporary API token generated by crates-io-auth-action lives unnecessarily longer than needed. The token exists during the entire cargo publish process, including package verification and compilation, creating an extended attack window.

Solution

This PR introduces cargo-credential-trusted-publish, a Cargo credential provider that:

1. Minimizes token lifetime: Tokens are acquired just-in-time only when needed for the actual publish operation
2. Automatic token management: Uses OIDC tokens from GitHub Actions to exchange for short-lived crates.io API tokens
3. Automatic cleanup: Tokens are revoked immediately after publish completion via the logout action
4. Zero configuration: Works automatically in GitHub Actions with id-token: write permissions
5. Secure by design: Only supports crates.io registry and publish operations

Key Features

• Protocol compliance: Implements Cargo's credential-provider protocol v1
• OIDC integration: Exchanges GitHub Actions OIDC tokens for crates.io API tokens
• Session caching: Optimized for workspace publishing (single token exchange per session)
• Comprehensive error handling: Clear error messages for all failure scenarios
• Fallback support: Gracefully falls back to existing credential providers

Security Benefits

• No stored secrets: Eliminates need for long-lived API tokens in CI
• Minimal attack surface: Tokens exist only during actual publish operations
• Environment validation: Only activates in proper OIDC-enabled CI environments

---

How to test and review this PR?

Code Review Focus Areas

1. Core Implementation (credential/cargo-credential-trusted-publish/src/lib.rs)

   • OIDC token exchange logic with crates.io endpoints
   • Credential provider protocol compliance
   • Token lifecycle management (acquire → cache → revoke)
   • Registry and operation validation

2. Security Features

   • Registry restriction (crates.io only)
   • Operation restriction (publish only)
   • Environment validation (ACTIONS_ID_TOKEN requirement)
   • HTTPS-only communication with rustls

3. Integration (credential/cargo-credential-trusted-publish/src/main.rs)

   • Proper binary entry point using cargo-credential library
   • Protocol version announcement

Testing Instructions

1. Unit Tests

cargo test -p cargo-credential-trusted-publish

Expected: 5 tests pass, 1 ignored (requires real OIDC token)

2. Protocol Testing

./credential/cargo-credential-trusted-publish/test_protocol.sh

Expected: All protocol interactions work correctly:

• Version announcement: {"v":[1]}
• Unsupported registry: {"Err":{"kind":"url-not-supported"}}
• Missing OIDC token: Proper error message
• Logout: {"Ok":{"kind":"logout"}}

3. Manual Protocol Testing

# Build the provider
cargo build --release -p cargo-credential-trusted-publish

# Test version announcement
echo "" | ./target/release/cargo-credential-trusted-publish
# Expected: {"v":[1]} followed by EOF error (normal)

# Test unsupported registry
echo '{"v":1,"registry":{"index-url":"https://example.com/registry","name":"example"},"kind":"get","operation":"publish","name":"test","vers":"0.1.0","cksum":"abc123"}' | ./target/release/cargo-credential-trusted-publish
# Expected: {"v":[1]} then {"Err":{"kind":"url-not-supported"}}

# Test supported registry without OIDC token
echo '{"v":1,"registry":{"index-url":"https://github.com/rust-lang/crates.io-index","name":"crates-io"},"kind":"get","operation":"publish","name":"test","vers":"0.1.0","cksum":"abc123"}' | ./target/release/cargo-credential-trusted-publish
# Expected: Error about missing ACTIONS_ID_TOKEN

4. GitHub Actions Integration Testing

Use the provided workflow (.github/workflows/trusted-publish-example.yml):

1. Setup: Copy workflow to your repository
2. Configure: Set workflow inputs (crate name, version)
3. Test: Run with dry_run: true first
4. Verify: Check that:
   • OIDC token is available
   • Credential provider installs successfully
   • Cargo configuration is set up correctly
   • Dry run publish works without errors

Review Checklist

• Security: Registry validation, operation restriction, OIDC requirement
• Protocol: Correct JSON request/response handling, error codes
• Integration: Proper use of cargo-credential library patterns
• Documentation: Clear README, inline comments, GitHub Actions example
• Testing: Comprehensive test coverage, manual testing scripts
• Error Handling: Graceful failures with helpful error messages

Expected Behavior

In GitHub Actions with OIDC:

1. Provider exchanges OIDC token for crates.io API token
2. Token is used for publish operation
3. Token is automatically revoked on completion

Outside GitHub Actions:

1. Provider returns "not-found" error
2. Cargo falls back to other credential providers
3. Normal token-based publishing continues to work

References

• Issue: #15743
• RFC: Trusted Publishing via OIDC (RFC 3691)
• Protocol: Cargo Credential Provider Protocol

[rustbot]

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ojuschugh1]

Thanks for all the detailed feedback! You're absolutely right on all points.

I should have started with the design discussion on #15743 instead of jumping straight to code. Looking at the issue again, there are still important questions about built-in vs plugin approach and protocol changes that need to be settled first.

On the technical side - yeah, I definitely need to check the actual crates-io-auth-action source for the real endpoints instead of guessing. And good point about libcurl vs reqwest - I should follow the existing patterns in Cargo rather than adding new dependencies.

The scope feedback is spot on too. I got carried away trying to show a complete solution when I should have focused just on the core credential provider functionality.

I'll close this PR and continue the discussion on the issue thread. Once we have more clarity on the design direction and it gets marked as accepted, I can submit a much more focused implementation.

Thanks for taking the time to review this thoroughly!