feat: Support selective ssl/tls backend in rust-server to optionally remove openssl

[dsteeley]

The rust-server always brings in hyper-openssl as a dependency even though it's not always required.
I've therefore reconfigured the features of rust-server to support removing hyper-openssl from the dependencies. Currently this isn't backwards compatible where the default features don't specify an SSL backend. Users wanting this function for their Client must specify client-tls or client-openssl.

This is an anti-pattern to standard feature flagging of TLS backend. @wing328 would it be acceptable to put a "breaking" change in where we set the default to be not including openssl and document that if users want to use hyper-openssl then they should select that feature?

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR solves a reported issue, reference it using GitHub's linking syntax (e.g., having "fixes #123" present in the PR description)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. @frol (2017/07) @farcaller (2017/08) @richardwhiuk (2019/07) @paladinzh (2020/05) @jacob-pro (2022/10) @dsteeley (2025/07)

---

Summary by cubic

Adds a single TLS feature for rust-server clients and removes the unconditional OpenSSL dependency. TLS (client-tls) is enabled by default; disable it for HTTP-only builds. Native-tls is used on macOS/Windows/iOS, OpenSSL elsewhere.

• New Features

  • Introduced client-tls with automatic backend selection; removed client-openssl.
  • Default features now include client-tls; opt out with --no-default-features --features=client.
  • Updated templates, samples, README, and CI to build HTTP-only and client-tls variants.

• Migration

  • TLS helpers in the swagger crate are gated behind client-tls.
  • Examples: HTTP-only: cargo build --no-default-features --features=client; HTTPS: cargo build --no-default-features --features=client,client-tls.

^{Written for commit b571442. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 43 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name=".github/workflows/samples-rust-server.yaml">

<violation number="1" location=".github/workflows/samples-rust-server.yaml:71">
P2: CI doesn’t build the `client-openssl` feature even though rust-server samples define it, so OpenSSL client builds can break without detection.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

16 issues found across 43 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="samples/server/petstore/rust-server/output/petstore-with-fake-endpoints-models-for-testing/README.md">

<violation number="1" location="samples/server/petstore/rust-server/output/petstore-with-fake-endpoints-models-for-testing/README.md:151">
P3: Conflicting documentation: the new `client-tls` feature is described as not enabled by default, but the HTTPS/TLS section says HTTPS support is included by default. Clarify which is correct to avoid misleading users about default features.</violation>
</file>

<file name="samples/server/petstore/rust-server/output/ping-bearer-auth/Cargo.toml">

<violation number="1" location="samples/server/petstore/rust-server/output/ping-bearer-auth/Cargo.toml:23">
P2: `client-tls` now unconditionally enables OpenSSL deps and is part of default features; this removes target-specific gating and can pull OpenSSL on macOS/Windows/iOS where native-tls was intended, risking build/toolchain issues.</violation>
</file>

<file name="samples/server/petstore/rust-server/output/petstore-with-fake-endpoints-models-for-testing/Cargo.toml">

<violation number="1" location="samples/server/petstore/rust-server/output/petstore-with-fake-endpoints-models-for-testing/Cargo.toml:25">
P2: `client-tls` now unconditionally enables OpenSSL/hyper-openssl, but the target-specific dependency gating was removed. This pulls OpenSSL on macOS/Windows/iOS, defeating the intended OS-specific backend selection and potentially breaking builds without OpenSSL.</violation>
</file>

<file name="modules/openapi-generator/src/main/resources/rust-server/README.mustache">

<violation number="1" location="modules/openapi-generator/src/main/resources/rust-server/README.mustache:133">
P2: Documentation contradicts the crate defaults: `client-tls` is included in default features but the README now claims it is not enabled by default.</violation>
</file>

<file name="samples/server/petstore/rust-server/output/ops-v3/README.md">

<violation number="1" location="samples/server/petstore/rust-server/output/ops-v3/README.md:152">
P2: README incorrectly states `client-tls` is not enabled by default, but Cargo.toml includes it in default features, which can mislead users about TLS dependency behavior.</violation>
</file>

<file name="samples/server/petstore/rust-server/output/ping-bearer-auth/README.md">

<violation number="1" location="samples/server/petstore/rust-server/output/ping-bearer-auth/README.md:116">
P3: README incorrectly states `client-tls` is not enabled by default, but Cargo.toml default features include `client-tls`, creating contradictory guidance about TLS support.</violation>
</file>

<file name="samples/server/petstore/rust-server/output/multipart-v3/README.md">

<violation number="1" location="samples/server/petstore/rust-server/output/multipart-v3/README.md:129">
P3: The README contains contradictory statements about whether TLS support is enabled by default (`client-tls` “Not enabled by default” vs “HTTPS support is included by default”). This inconsistency can mislead users about required features.</violation>
</file>

<file name="samples/server/petstore/rust-server/output/no-example-v3/README.md">

<violation number="1" location="samples/server/petstore/rust-server/output/no-example-v3/README.md:115">
P2: The README introduces contradictory statements about TLS defaults (`client-tls` “Not enabled by default” vs “HTTPS support is included by default”), which can mislead users configuring features.</violation>
</file>

<file name="samples/server/petstore/rust-server/output/openapi-v3/README.md">

<violation number="1" location="samples/server/petstore/rust-server/output/openapi-v3/README.md:146">
P2: README claims `client-tls` is not enabled by default, but Cargo.toml includes it in default features. This documentation inconsistency can mislead users about TLS being enabled by default.</violation>
</file>

<file name="samples/server/petstore/rust-server/output/rust-server-test/README.md">

<violation number="1" location="samples/server/petstore/rust-server/output/rust-server-test/README.md:133">
P2: The README now contradicts itself about whether TLS is enabled by default (`client-tls` says not enabled by default, but the HTTPS/TLS section says HTTPS support is included by default). This can mislead users configuring Cargo features.</violation>
</file>

<file name="samples/server/petstore/rust-server/output/no-example-v3/Cargo.toml">

<violation number="1" location="samples/server/petstore/rust-server/output/no-example-v3/Cargo.toml:23">
P2: `client-tls` now enables OpenSSL dependencies unconditionally and is part of `default`, so macOS/Windows builds will compile `openssl`/`hyper-openssl` even though those platforms should use native-tls. This removes prior target gating and can cause build failures when OpenSSL toolchains aren’t available.</violation>
</file>

<file name="samples/server/petstore/rust-server/output/multipart-v3/Cargo.toml">

<violation number="1" location="samples/server/petstore/rust-server/output/multipart-v3/Cargo.toml:25">
P2: `client-tls` now unconditionally enables `dep:openssl`/`dep:hyper-openssl` while OpenSSL deps are in global `[dependencies]`, so default builds pull OpenSSL on all targets (macOS/Windows/iOS included) despite the intended per-OS backend selection.</violation>
</file>

<file name="samples/server/petstore/rust-server/output/openapi-v3/Cargo.toml">

<violation number="1" location="samples/server/petstore/rust-server/output/openapi-v3/Cargo.toml:25">
P2: `client-tls` now unconditionally enables OpenSSL deps after removing target-specific dependency blocks, so default builds will pull `openssl`/`hyper-openssl` on all targets, undermining the selective TLS backend goal and risking build failures on platforms without OpenSSL.</violation>
</file>

<file name="modules/openapi-generator/src/main/resources/rust-server/Cargo.mustache">

<violation number="1" location="modules/openapi-generator/src/main/resources/rust-server/Cargo.mustache:60">
P2: `client-tls` unconditionally enables both OpenSSL and native-tls dependencies after removing target-specific gating, so OpenSSL crates are built on all targets when default features are enabled, contradicting the selective-backend intent and potentially reintroducing unwanted OpenSSL build requirements.</violation>
</file>

<file name="samples/server/petstore/rust-server/output/rust-server-test/Cargo.toml">

<violation number="1" location="samples/server/petstore/rust-server/output/rust-server-test/Cargo.toml:23">
P2: `client-tls` is now a default feature and unconditionally enables OpenSSL dependencies for all targets. That forces OpenSSL builds on macOS/Windows/iOS despite the intended native-tls backend and can break builds when OpenSSL isn’t installed.</violation>
</file>

<file name="samples/server/petstore/rust-server/output/ops-v3/Cargo.toml">

<violation number="1" location="samples/server/petstore/rust-server/output/ops-v3/Cargo.toml:23">
P2: `client-tls` is now a default feature and unconditionally enables `openssl`/`hyper-openssl` after removing target-specific dependency gating, which pulls OpenSSL on macOS/Windows/iOS and defeats the intended platform-specific TLS backend selection.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[dsteeley]

@cubic-dev-ai please re-review

[cubic-dev-ai]

@cubic-dev-ai please re-review

@dsteeley I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 43 files