fix: migrate Rust crate publishing from cargo publish to ESRP Release

[imran-siddique]

Per EngHub guidance, all Microsoft Rust packages must publish through ESRP Release under the \microsoft-oss-releases\ crates.io account.

Changes

• Pipeline: Replace \cargo publish\ with \EsrpRelease@11\ (contenttype: \Rust)
• Build: \cargo package\ → copy .crate\ to pipeline workspace
• Publish: ESRP handles signing, scanning, and crates.io API upload
• No \CRATES_IO_TOKEN\ needed — uses shared ESRP config

Docs

• Updated PUBLISHING.md Rust section to reflect ESRP
• Updated pipeline overview table

[github-actions]

🤖 AI Agent: code-reviewer

Review Feedback for Pull Request: "fix: migrate Rust crate publishing from cargo publish to ESRP Release"

---

🔴 CRITICAL: Security Concerns

1. Pipeline Artifact Handling:

   • The .crate files are copied to the pipeline workspace ($(Pipeline.Workspace)/rust-packages) and later published via ESRP. Ensure that the workspace is isolated and not accessible by other jobs or stages in the pipeline. If the workspace is shared, malicious actors could tamper with the .crate files before ESRP processes them.
   • Action: Add explicit pipeline isolation or integrity checks (e.g., checksum validation) before invoking ESRP.

2. ESRP Configuration Secrets:

   • The ESRP task uses sensitive inputs such as keyvaultname, signcertname, and clientid. Ensure these secrets are stored securely in Azure Key Vault or equivalent and are not exposed in pipeline logs.
   • Action: Confirm that $(ESRP_KEYVAULT_NAME), $(ESRP_CERT_IDENTIFIER), and other secrets are securely managed and not hardcoded in the pipeline YAML.

3. Malware Scanning:

   • While ESRP performs malware scanning, there is no pre-ESRP validation of the .crate files. If the .crate files are tampered with before ESRP processing, this could lead to malicious code being signed and published.
   • Action: Add a pre-ESRP step to verify the integrity of the .crate files (e.g., hash comparison against a known good state).

---

🟡 WARNING: Potential Breaking Changes

1. Crates.io Account Migration:

   • The migration to the microsoft-oss-releases account changes the ownership of published crates. This could impact downstream consumers relying on the previous account for updates.
   • Action: Communicate this change clearly in release notes and documentation. Consider providing a transition guide for consumers.

2. Yanking Crates:

   • The removal of programmatic yanking via cargo yank introduces operational overhead (IcM incidents). This could delay critical security fixes requiring crate yanking.
   • Action: Work with the ESRP team to prioritize adding programmatic yanking support.

---

💡 SUGGESTIONS: Improvements

1. Pipeline Documentation:

   • The updated PUBLISHING.md is clear but could benefit from a diagram showing the ESRP pipeline flow for Rust crates. Visual aids help onboard new contributors faster.
   • Action: Add a diagram illustrating the ESRP pipeline stages for Rust crate publishing.

2. Checksum Validation:

   • Enhance the pipeline by generating and validating checksums for .crate files before publishing. This ensures file integrity and prevents tampering.
   • Action: Add a step to compute and validate SHA256 checksums for .crate files.

3. Dry Run Testing:

   • The pipeline conditionally skips publishing when dryRun is true. Consider adding a dry-run mode for ESRP to simulate the release process without actual publishing.
   • Action: Investigate ESRP's support for dry-run functionality and integrate it into the pipeline.

4. Backward Compatibility:

   • While the ESRP migration is necessary, ensure that the pipeline supports legacy publishing methods (cargo publish) for emergency scenarios or backward compatibility.
   • Action: Add a fallback mechanism to allow manual cargo publish if ESRP is unavailable.

---

Summary

This pull request introduces a critical migration to ESRP Release for Rust crate publishing, aligning with Microsoft OSS guidelines. While the changes improve security and compliance, there are critical concerns around pipeline artifact handling and pre-ESRP validation. Addressing these issues will ensure the integrity and security of published crates. Additionally, breaking changes like account migration and yanking limitations should be communicated effectively to downstream consumers.

[github-actions]

🤖 AI Agent: security-scanner — Security Review of PR: Migrate Rust Crate Publishing to ESRP Release

Security Review of PR: Migrate Rust Crate Publishing to ESRP Release

This PR replaces the existing cargo publish process for publishing Rust crates to crates.io with the ESRP Release pipeline. The ESRP pipeline introduces additional security measures, such as code signing, malware scanning, and centralized credential management. Below is a security analysis of the changes.

---

Findings

1. 🔵 LOW: Removal of CRATES_IO_TOKEN from Pipeline

• Issue: The PR removes the need for a CRATES_IO_TOKEN in the pipeline, relying instead on ESRP's centralized configuration and managed identity for authentication. This reduces the risk of credential exposure in the pipeline.
• Impact: Positive security improvement. Secrets are no longer stored in pipeline variables, reducing the attack surface for credential theft.
• Recommendation: None. This is a positive change.

---

2. 🟡 MEDIUM: ESRP Configuration Validation

• Issue: The ESRP configuration relies on several parameters (ESRP_KEYVAULT_NAME, ESRP_CERT_IDENTIFIER, ESRP_CLIENT_ID, etc.) that are passed into the pipeline. If these parameters are misconfigured or tampered with, it could lead to publishing failures or unauthorized access.
• Attack Vector: An attacker with access to the pipeline configuration could potentially modify these parameters to redirect the publishing process or compromise the trust chain.
• Recommendation:
  • Validate that all ESRP configuration parameters are securely stored and immutable in the pipeline.
  • Use Azure Key Vault or a similar secure secret management system to store and retrieve these parameters.
  • Implement pipeline-level access controls to restrict who can modify these parameters.

---

3. 🔵 LOW: Removal of Direct cargo publish

• Issue: The PR removes the direct use of cargo publish, which previously relied on a personal API token (CARGO_REGISTRY_TOKEN). This eliminates the risk of token misuse or exposure.
• Impact: Positive security improvement. Centralized publishing through ESRP reduces the risk of human error or token leakage.
• Recommendation: None. This is a positive change.

---

4. 🟠 HIGH: Lack of Verification for .crate Files

• Issue: The pipeline packages the crate using cargo package and then uploads the .crate file to ESRP for signing and publishing. However, there is no verification step to ensure the integrity of the .crate file before it is handed off to ESRP.
• Attack Vector: A malicious actor with access to the pipeline could tamper with the .crate file after it is packaged but before it is uploaded to ESRP. This could lead to the publication of a compromised crate.
• Recommendation:
  • Add a step to compute and log the checksum (e.g., SHA-256) of the .crate file immediately after packaging.
  • Verify the checksum before uploading the file to ESRP to ensure its integrity.
  • Consider implementing a mechanism to compare the checksum of the uploaded file with the locally computed checksum.

---

5. 🔵 LOW: Dependency on ESRP

• Issue: The pipeline now relies entirely on ESRP for publishing. While ESRP provides enhanced security features, any vulnerabilities or misconfigurations in ESRP could impact the publishing process.
• Impact: Dependency on a centralized service introduces a single point of failure.
• Recommendation:
  • Regularly audit ESRP configurations and access controls.
  • Establish a fallback or contingency plan for publishing in case of ESRP outages or incidents.

---

6. 🔵 LOW: Documentation Updates

• Issue: The updated documentation reflects the new ESRP-based publishing process but does not include details on how to verify the integrity of the published crate.
• Impact: Users may not be aware of how to verify the authenticity of the published crate.
• Recommendation: Update the documentation to include instructions for downstream users on verifying the authenticity of the published crate (e.g., using the signature or checksum).

---

Summary of Findings

Finding	Severity	Recommendation
Removal of CRATES_IO_TOKEN	🔵 LOW	No action needed. Positive security improvement.
ESRP Configuration Validation	🟡 MEDIUM	Ensure ESRP parameters are securely stored and immutable.
Removal of Direct cargo publish	🔵 LOW	No action needed. Positive security improvement.
Lack of Verification for .crate Files	🟠 HIGH	Add checksum verification for .crate files before uploading to ESRP.
Dependency on ESRP	🔵 LOW	Regularly audit ESRP configurations and establish a fallback plan.
Documentation Updates	🔵 LOW	Include instructions for verifying the authenticity of published crates.

---

Final Assessment

This PR introduces significant security improvements by migrating to ESRP for Rust crate publishing. However, the lack of verification for .crate file integrity before uploading to ESRP is a notable gap that could be exploited by an attacker with access to the pipeline. Addressing this issue is critical to ensure the integrity of the published crates.

Overall Rating: 🟠 HIGH (due to the lack of .crate file verification).

Suggested Next Steps

1. Implement .crate file checksum verification in the pipeline.
2. Secure ESRP configuration parameters and validate their integrity.
3. Update documentation to include instructions for verifying published crate authenticity.

Let me know if you need further assistance!