Skip to content

Conversation

@muhammad-hassnain
Copy link
Collaborator

I added rust-toolchain.toml to pin to rustc-1.85.0

Without this, running rustup update updates toolchain to rustc 1.89.0 as of August 16,2025.

Running cargo build after that fails to compile cargo-scan because one of the dependency ra_ap_stdx-0.0.185 performs a cast which is no longer supported. I am also quoting the compiler error message below:

[PATH]/index.crates.io-1949cf8c6b5b557f/ra_ap_stdx-0.0.185/src/anymap.rs:283:40
    |
283 |                 unsafe { Box::from_raw(raw as *mut $t) }
    |                                        ^^^^^^^^^^^^^^ unsupported cast
...
378 | impl_clone!(dyn CloneAny + Send);
    | -------------------------------- in this macro invocation
    |
    = note: this could allow UB elsewhere
    = help: use `transmute` if you're sure this is sound
    = note: this error originates in the macro `impl_clone` (in Nightly builds, run with -Z macro-backtrace for more info)

with rust-toolchain-toml added the compilation succeeds with this warning :

warning: the following packages contain code that will be rejected by a future version of Rust: ra_ap_stdx v0.0.185
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`

I have also removed 2. Run rustup update to ensure you have the latest version of Rust (or install it via the [official website]((https://www.rust-lang.org/tools/install))). from README.md because a working version has been pinned.

@cdstanford
Copy link
Collaborator

@muhammad-hassnain Thanks! Let me check on my machine and see if I can build.

@cdstanford
Copy link
Collaborator

@muhammad-hassnain It seems to build for me, I get only a warning:

$ cargo build
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.37s
warning: the following packages contain code that will be rejected by a future version of Rust: ra_ap_stdx v0.0.185
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 2`
$ cargo --version
cargo 1.85.0 (d73d2caf9 2024-12-31)
$ rustc --version
rustc 1.85.0 (4d91de4e4 2025-02-17)

Is this different from what you're seeing on your end?

@muhammad-hassnain
Copy link
Collaborator Author

No, I see the same warning after version pinning. It works perfectly fine on 1.85.0. But if you have rustc 1.89.0 which you can install using rustup update , the build fails.

@cdstanford
Copy link
Collaborator

Oops, I see. Let me check that. If we can't get it to build on 1.89 we will need to hold off on merging this PR until we can fix the RA issue.

@muhammad-hassnain
Copy link
Collaborator Author

I will also look into this RA issue, but I think we should merge this, because in case anyone has 1.89 , the rust-toolchain.toml file, will use 1.85 to build. so this can be a placeholder patch.

@cdstanford
Copy link
Collaborator

I see. Not sure why the build is breaking then - @muhammad-hassnain can you check into why checks/clippy, checks/fmt, and update/update are failing? Maybe it is that we need to update something in .github/workflows...

@muhammad-hassnain
Copy link
Collaborator Author

I have fixed the clippy and fmt issue, but the update workflow still fails. This is because the PR is coming from a fork, and the update workflow checks out from that. So the GITHUB_TOKEN has read-only permissions for security reasons and that causes the push to fail.

https://stackoverflow.com/questions/74957218/what-is-the-difference-between-pull-request-and-pull-request-target-event-in-git?utm_source=chatgpt.com

I found this interesting post, a workaround for this is to use pull request target , but the post also mentions:

"That is inherently risky if the workflow inadvertently exposes these secrets or allows for unauthorized modifications to the repository.

Another risk: the workflow attempts to check out and execute code from the pull request. Since this event runs in the context of the target branch with access to secrets, executing code from the PR without strict controls can expose secrets to untrusted code."

So, maybe we should not run this workflow on a PR ?

@cdstanford
Copy link
Collaborator

Hmm very strange @muhammad-hassnain
But in fact, the checks seem to now be passing - all except Update, so I will go ahead and merge and see if it works. Thanks for the PR!

@cdstanford cdstanford merged commit 912e440 into PLSysSec:main Aug 19, 2025
5 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants