Skip to content
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

Feature Request: new API to set s2n_connection->config to default config #4984

Open
boquan-fang opened this issue Dec 17, 2024 · 2 comments
Open

Comments

@boquan-fang
Copy link
Contributor

Problem:

The config pointer in s2n_connection struct might be invalid during connection reuse. The s2n_config struct could be released at sometime before the s2n_connection struct is reused, which makes the pointer pointing to an invalid address, when the connection is actually reused.

Solution:

Create a new API which reset the config pointer in s2n_connection to the default config that the user is using. This can also simplify the management of s2n_connection without requiring deep understanding of how s2n_config is stored in s2n_connection.

Requirements / Acceptance Criteria:

After we wipe a s2n_connection struct and make it ready for connection reuse, we should test whether the config pointer is pointing to the default config.

@jmayclin
Copy link
Contributor

Personal Opinion: I don't like concept of a default config, and I'd vote against embracing it more strongly. Since people currently can't rely on this behavior, I'd vote for going towards the other end of the spectrum and instead adding an API to null out the config.

@goatgoose
Copy link
Contributor

Nulling out the config would work in theory, but would be scary due to the number of places we rely on there being a non-null config without checking it first.

Another similar option: we make s2n_connection_set_config(NULL) set a poison config that behaves as though you set a null config, but isn't actually null.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants