Skip to content

Stub-out assorted functions for haproxy #76

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

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Conversation

ctz
Copy link
Member

@ctz ctz commented May 27, 2025

In pursuit of #62

@ctz ctz force-pushed the jbp-haproxy-stubs branch from 180df30 to 544f41a Compare May 27, 2025 12:09
Copy link
Member

@djc djc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the process here? This helps the target app compile and then you can figure out which ones are actually called?

@ctz
Copy link
Member Author

ctz commented May 27, 2025

What's the process here? This helps the target app compile and then you can figure out which ones are actually called?

Not actually recompiling the target app; this is a link-time replacement library (in other words, the application is already compiled against OpenSSL 3, and the goal is to work with it as-is.)

The process is something like:

  1. Run the target executable and capture logs from the dynamic linker. This data goes into the "haproxy" column of https://github.com/rustls/rustls-openssl-compat/blob/main/MATRIX.md . It is a list of all the symbols haproxy requires from libssl.so in order to dynamically link. That was Add haproxy 2.8.5-1ubuntu3.3 to compatibility matrix #72

  2. Look at https://github.com/rustls/rustls-openssl-compat/blob/main/MATRIX.md and choose a line where the "haproxy" column is checked, but the "implemented?" is empty. Each such line would mean haproxy will fail to dynamically link, and you'll get an error like "haproxy: symbol lookup error: haproxy: undefined symbol: SSL_set_client_CA_list, version OPENSSL_3.0.0"

  3. Work out what that symbol does and how haproxy uses it; consulting openssl documentation and haproxy source.

  4. The function can be stubbed if haproxy is pretty happy if the function just returns an error, or the function has no observable effect, or is peripheral to other APIs that are also stubs, etc.

    eg, in this PR SSL_SESSION_get_max_early_data has a documented base case of returning zero (meaning early data is disabled) so that works logically for now.

@djc
Copy link
Member

djc commented May 27, 2025

What's the process here? This helps the target app compile and then you can figure out which ones are actually called?

Not actually recompiling the target app; this is a link-time replacement library (in other words, the application is already compiled against OpenSSL 3, and the goal is to work with it as-is.)

The process is something like:

  1. Run the target executable and capture logs from the dynamic linker. This data goes into the "haproxy" column of https://github.com/rustls/rustls-openssl-compat/blob/main/MATRIX.md . It is a list of all the symbols haproxy requires from libssl.so in order to dynamically link. That was Add haproxy 2.8.5-1ubuntu3.3 to compatibility matrix #72

  2. Look at https://github.com/rustls/rustls-openssl-compat/blob/main/MATRIX.md and choose a line where the "haproxy" column is checked, but the "implemented?" is empty. Each such line would mean haproxy will fail to dynamically link, and you'll get an error like "haproxy: symbol lookup error: haproxy: undefined symbol: SSL_set_client_CA_list, version OPENSSL_3.0.0"

  3. Work out what that symbol does and how haproxy uses it; consulting openssl documentation and haproxy source.

  4. The function can be stubbed if haproxy is pretty happy if the function just returns an error, or the function has no observable effect, or is peripheral to other APIs that are also stubs, etc.
    eg, in this PR SSL_SESSION_get_max_early_data has a documented base case of returning zero (meaning early data is disabled) so that works logically for now.

Is something like this comment already in something like a CONTRIBUTING.md or somewhere else permanent? Would be useful IMO.

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