-
-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NSInvalidArgumentException with Cargo package on macOS Sonoma #8
Comments
I ran in the same exception with an old Intel-based Mac. As a quick workaround, you could set to "false" the "auto_sys_proxy" property of ClientBuilder inside reqwest::Client. As far as I understood, the problem is in retrieving system proxy information when calling Client::default() |
Mmm interesting, this seems to be a Cargo issue: rust-lang/cargo#12784 @vinniejames do you have a stack trace you can paste here? |
Interesting indeed, because the previous release build seemed to work properly apparently it has something to do with proxy retrieval while initing reqwest client as previously mentioned.
until @evilsocket or cargo come up with a proper solution for everyone facing the same issue, here is a quick workaround: Install the latest cURL via Homebrew and then run one of the following commands. DYLD_INSERT_LIBRARIES=/opt/homebrew/opt/curl/lib/libcurl.dylib ./legba
or just export DYLD_INSERT_LIBRARIES=/opt/homebrew/opt/curl/lib/libcurl.dylib
./legba
|
thanks @0xsha, by previous release build you mean macOS, reqwest, curl or legba? |
@evilsocket Legba, the last time I built it was a few days ago on a M1 Mac machine. The release version works without the need for inserting DYLD, and it was on the same macOS Sonoma. default mac cURL version
Homebrew cURL version
current reqwest is matched with main branch
|
Weird, as far as I can remember reqwest version was not changed https://github.com/evilsocket/legba/blame/main/Cargo.toml#L36 |
It is indeed strange, but as is it certainly affects the default release build on M1 if there's a plan to distribute a binary release of Legba through Homebrew and other binary distribution channels. probably following up cargo issues might give more clues. |
will do my best to understand this better, your feedback has been extremely valuable @0xsha, thank you so much |
okay had some time to actually debug it. the actual fix is here : for now a better workaround than
is to first install latest curl with homebrew brew install curl add a use std::env;
use std::path::PathBuf;
fn main() {
if env::var("CARGO_CFG_TARGET_OS").unwrap() == "macos"
// && env::var("CARGO_CFG_TARGET_ARCH").unwrap() == "aarch64"
{
let lib_dir = PathBuf::from(env::var("HOMEBREW_PREFIX").unwrap_or("/opt/homebrew".into()))
.join("lib");
let include_dir =
PathBuf::from(env::var("HOMEBREW_PREFIX").unwrap_or("/opt/homebrew".into()))
.join("include");
// Tell cargo to link against libcurl from Homebrew
println!("cargo:rustc-link-search=native={}", lib_dir.display());
println!("cargo:rustc-link-lib=curl");
println!("cargo:include={}", include_dir.display());
}
} now just build a release as you normally do cargo build --release and everything should work as it was ! ➜ legba git:(main) ✗ ./target/release/legba --version
legba v0.3.0 I haven't created a pull request yet because I'm waiting to see if the issue can be resolved with the new Cargo update or if @evilsocket has a better idea regarding the build.rs file. However, this is certainly the appropriate solution for distribution if needed. Enjoy ! |
@evilsocket didn't fix it and it still crashes, as that workaround doesn't seem to be a workaround. Read my last workaround; the core issue is linked to the version of cURL |
it was worth trying :/ |
@0xsha pushed your build.rs, thanks ... honestly I feel a bit dumb because I don't understand at which point curl is involved. Reqwest doesn't seem to link/reference it anywhere: |
says he feels dumb, one of the best infosec tool developers alive! The proposed |
lol i feel dumb more often than you'd imagine XD ... i'll try to dig into it, maybe i can identify what the hell is using libcurl and why |
I upgraded to Sonoma and finally was able to reproduce on M1. This is the output of bt from an lldb session:
The issue is caused by this call https://github.com/seanmonstar/reqwest/blob/50dbaf391087cfa951accc765126b4f5d017d8a3/src/proxy.rs#L946 which references the system_configuration crate which ultimately ends up calling this https://github.com/mullvad/system-configuration-rs/blob/main/system-configuration-sys/src/dynamic_store_copy_specific.rs#L35 Looks like libcurl is somehow invoked by Sonoma to return the current system proxy settings from SCDynamicStoreCopyProxies ... I wonder how this happens since there're no direct libcurl invokations ... anyways, I've pushed a fix that doesn't require us to link explicitly to libcurl ... @p1tsi was correct, I just forgot to add the fix to the constructor of the HTTP plugin, that called a reqwest::Client::new() :D thanks all for the help! |
Installed on an M2 with
cargo
, every command fails with the same error:The text was updated successfully, but these errors were encountered: