1.x: Bump MSRV to Rust 1.88.0 for ecosystem compatibility
Moves MSRV from 1.85.0 to 1.88.0 — this keeps us positioned to pull in security and bug fix updates from the ecosystem without getting stuck. Not moving to Rust 1.91 (more current Rust) since this is a Maintenance LTS line and less changes seem preferable.
Already seeing deps like aws-sdk-sso, aws-sdk-ssooidc, and aws-sdk-sts requiring 1.88+, so this is about staying agile rather than responding to an immediate security issue.
Necessarily fixes a test compatibility issue with Rust 1.88.0's panic message formatting in caching_query_planner.rs — it now has to use starts_with() instead of exact string matching.
No breaking changes for binary users — only affects library consumers who need to update their Rust toolchain to 1.88.0+.
Changes
- Update Rust to 1.88.0
- Fix
caching_query_planner.rstest for Rust 1.88.0 panic message format - Add changeset documenting the MSRV bump
✅ Docs preview ready
The preview is ready to be viewed. View the preview
File Changes
0 new, 1 changed, 0 removed
* graphos/routing/v1/customization/custom-binary.mdx
Build ID: e1eb2bf454e6e99feac0130a Build Logs: View logs
URL: https://www.apollographql.com/docs/deploy-preview/e1eb2bf454e6e99feac0130a
there's a few other places that reference the rust version, easiest to identify by:
rg 'renovate-automation: rustc version' -A1
I did find more, after I pushed.
ah, looks like there's some more I should look at, too.
The lint failures for format! are somewhat tragic, but could be somewhat easily applied.
Yeah the clippy changes is why I wasn't sure whether to do this when I had a few-minute look last week. It's either that or recursively pinning dependency versions, which I'm not sure how to do, and might be a problem if there's a security issue in the future. Or I guess disabling lints, but shrug.
The format!() changes can be autofixed by clippy.
I did successfully recursively pin the dependencies, however, it was REALLY messy and left us on worryingly old versions of things. I'll look at clippy fixes.
Detected SAST Vulnerabilities
:red_circle: Potential Security Issues Found
If you are seeing this message, it means that the security scanning tool that Apollo uses to test our source has identified a potential security issue in code introduced or updated via your branch. Information about what was detected and steps to move forward are below.
If the scanner detected a legitimate issue, please take action to correct it prior to merging this PR. The action required will vary based on the detection. If the detection is a false positive, please follow the steps below to resolve the issue.
Issues Detected
| Message | Caused CI Failure? | Link | Path | Signature |
|---|---|---|---|---|
| Insecure WebSocket Detected. WebSocket Secure (wss) should be used for all WebSocket connections. | Yes | Link | apollo- router/src/protocols/websocket.rs | rules.providers.semgrep.security.ja vascript.lang.security.detect- insecure-websocket |
| Insecure WebSocket Detected. WebSocket Secure (wss) should be used for all WebSocket connections. | Yes | Link | apollo- router/src/protocols/websocket.rs | rules.providers.semgrep.security.ja vascript.lang.security.detect- insecure-websocket |
False Positive Resolution Process
The easiest way to resolve a false positive is to add a comment containing nosemgrep to the code that triggered the detection. You can add the comment directly to the line triggering the detection or on the line immediately above it. For example:
#!/usr/bin/env python3
def my_function():
my_code_generating_detection() # nosemgrep
What if I can't add a line comment?
If you can't add a comment because the detection is generated by a file that does not support comments (like JSON), you can use Semgrep's .semgrepignore file. For more information about how to create an exclusion via .semgrepignore, refer to the Semgrep documentation.
Getting Help
The Apollo Security team is available to assist in resolving this issue. Please tag us on this PR using @apollographql/security if you need assistance!