ICE dumps leak user names etc

rust-lang / rust

Empowering everyone to build reliable and efficient software.

https://www.rust-lang.org

Other

96.79k stars 12.5k forks source link

ICE dumps leak user names etc #128594

Open matthiaskrgr opened 1 month ago

matthiaskrgr commented 1 month ago

When you trigger an ICE, rustc generates this stacktrace file and prints its location as absolute path:

note: please attach the file at /home/matthias/vcs/github/rust/rustc-ice-2024-08-03T09_07_05-3443169.txt to your bug report

This absolute path is part of the backtrace and often copied into the ticket and can contain sensitive information such as users real names or where they work, when its a work computer, etc...

Can we make this a relative path? cc @estebank

jieyouxu commented 1 month ago

Pretty sure long ty names written to disk also has this issue EDIT: opened #129296 so that is separately tracked.

Noratrieb commented 1 month ago

making it a relative path would likely hurt usability, cargo sets the working directory to the crate source which is not necessarily the working directory of the user. it would be bad if they couldn't just copy paste the path and open it.

matthiaskrgr commented 1 month ago

Ah good point, in case a crate dependency causes the ICE, the backtrace file gets dumped into random dirs inside the $CARGO_HOME which is even worse (registry crate sources really shouldn't be altered at all during builds...), see https://github.com/rust-lang/rust/issues/128484 for an example.

We could probably fix 99% of the cases by checking if there is a something like a /tmp and using that one if available?

bjorn3 commented 1 month ago

Could we replace a prefix matching the user's home dir with ~/ on Unix and with %userprofile% on Windows (or assume that most Windows users understand the ~/ syntax too)?

estebank commented 1 month ago

I think that we can likely use a combination of the above strategies. @yaahc just happens to be looking into making the target directory a user definable nightly config flag (instead of an env flag) so that cargo can pass it in and specify a directory in the same way that they are talking about global caching of artifacts (cc @epage). That would likely also have the issue of the username being part of the path printed to stderr. I think if we can reliably use ~/ and %userprofile%, that would likely be the best option.

yaahc commented 1 month ago