How to build without ring?

[xnox]

rcgen should be an optional feature, and yet it seems to be always compiled...

# install cargo-auditable plugin
cargo install cargo-auditable
# install rust-audit-info inspection binary
cargo install rust-audit-info
# build ztunnel binary with audit information, no default features, just tls-boring feature
# expectation is that this binary does not pull in rcgen nor ring
cargo auditable build --bin ztunnel --no-default-features --features tls-boring --release
# observe that rcgen & ring packages are pulled into ztunnel binary
rust-audit-info ./out/rust/release/ztunnel | jq -r '.packages | .[] | .name' | grep -e '^rcgen' -e '^ring'
rcgen
ring

Built on master, 1.24.0-alpha.0-33-g0ad78e3, 0ad78e3

Am i missing something?

It seems to me that somehow, via testing feature & dev-dependencies rcgen is always enabled; when it should be optional.

Or is there a bug in the generated rust-audit-info?

[xnox]

Executing:

cargo remove rcgen
cargo remove ring

Appears to remove rcgen & ring from Cargo.toml and lock files.

Rebuilding the binary shows that boring crate, ends up pulling in rustls, and ends up pulling in ring.

Shouldn't the boring crate pull in rustls with custom-provider feature set?

[xnox]

Executing

cargo add --no-default-features --features custom-provider,tls12 [email protected]

Still pulls in ring =(

[howardjohn]

hmmm..

$ cargo tree --no-default-features --features tls-boring -e normal | grep ' ring'

finds no matches. Seems like a bug in cargo-audit or cargo-tree.

$ strings ./out/rust/debug/ztunnel | rg rcgen has none either - not sure that is a very valid check, though - but with the ring build it does show up rcgen so that adds some credibility.

[xnox]

Hopefully opened a better bug info:

• Is there a good way to visualise rust-audit-info json? (Also additional dependencies may be present) rust-secure-code/cargo-auditable#182

So here is what I did:

git clone https://github.com/istio/ztunnel
cd ztunnel
export ZTUNNEL_BUILD_buildStatus=clean
export ZTUNNEL_BUILD_buildGitRevision=$(git rev-parse HEAD)
export ZTUNNEL_BUILD_buildTag=$(git describe --tags --abbrev=0)
export ZTUNNEL_BUILD_buildVersion=$(git rev-parse HEAD)
cargo auditable build --release --no-default-features --features tls-boring --bin ztunnel

During build log ring v0.17.8 was downloaded

    Updating crates.io index
    Updating git repository `https://github.com/janrueth/boring-rustls-provider`
  Downloaded aead v0.5.2
  Downloaded anes v0.1.6
  Downloaded anstyle v1.0.10
...
  Downloaded symbolic-common v12.12.4
  Downloaded split-iter v0.1.0
  Downloaded netns-rs v0.1.0
  Downloaded ring v0.17.8
  Downloaded httparse v1.9.5
  Downloaded tracing-attributes v0.1.28
  Downloaded same-file v1.0.6
...

Then used rust-audit-info out/rust/release/ztunnel > /tmp/ztunnel.json and tried to interpret it, step by step, as described in:

• Is there a good way to visualise rust-audit-info json? (Also additional dependencies may be present) rust-secure-code/cargo-auditable#182

It seems that ztunnel depends on boring-rustls-provider (29) & rustls (239).
boring-rustls-provider (29) depends on both rustls (239) and rustls-webpki (243).
And finally "rustls-webpki" depends on ring (232).

The question I have is does ztunnel use rustls-webpki? and does that indeed use ring? or is boring backend called instead? Is it possible to substitute in ring that will print at runtime if it was used, or somehow use debugger to add breakpoints upon using ring? Or is it possible to somehow make boring-rutls-provider and ztunnel dependencies on rustls to not pull in ring via rustls-webpki dependencies?

Is it a cargo problem? rustls problem? or boring-rustls-provider problem?

ztunnel.json.txt.gz

[howardjohn]

https://github.com/janrueth/boring-rustls-provider/blob/aa6e1c36f880002ceb56f99a64d19e0503e0bec7/Cargo.toml#L26 - this should be disabling ring. Given the objdump and cargo tree both indicate no ring usage, which is what appears correct looking at the dependencies, I'm inclined to think it's a cargo suit issue.

Maybe one way to be very sure would be to point to a local ring fork that panics if it's linked to or something