How do default values in the OpenSSL code base get changed?
OpenSSL contains many default values in its code base, e.g., for [default TLS groups](https://openssl-communities.org/d/dpuCvbRz/post-quantum-cryptography-pqc-group-recommendations-for-tls-1-3/15). These default values are valid only at a given point in time and may change as for example, needs, risks or standards change.
This discussion thus is to request a documentation to a "recommended procedure" how changes to these values can be initiated: Is this always simply by way of a GH PR or would TACs/BACs need to be involved? If the latter, how?
If different procedures are considered sensible for different defaults (arguably advisable) should there be a list of all defaults and the way each can get changed in the project (or outside it, e.g., if they are linked to a standard)? Maybe also sensible would be a documented link to the person(s) most likely to comment on a proposed default value change (or a link to the code base for each default such as to check `git blame` who last changed it).
If this already exists, apologies for the noise and thanks in advance for a pointer to it.
Neil Horman Wed 24 Sep 2025 2:07PM
It might be worth breaking out "Default values" to independent categories for the purpose of what may or may not need some additional approval. some example categories:
1) Standards based defaults (such as TLS_DEFAULT_CIPHERSUITES)
2) localized openssl defaults (OPENSSL_MODULES)
3) application defaults (i.e. configuration defaults)
4) something I'm sure I've not thought of.
I imagine there exists some set of categories that advisory committees may (or may not) want input on.
Additionally, just because I mention this any time we talk about inserting influence/control on a given change, we should probably talk about how that control is asserted. Just mandating it is a sure fire way to forget to do it, or not realize it needs to be done. We should ensure that there is some automation around detection of those issues which advisory groups want input on, vs those that aren't relevant.
Paul Yang Thu 25 Sep 2025 12:35AM
GH PRs are enough IMHO
Michael Baentsch Wed 1 Oct 2025 6:03AM
Thanks @Dmitry Belyavsky @Neil Horman @Paul Yang for your feedback -- and particulary Neil for a nuanced view that I share.
Regarding the original question, I do agree that a PR is the easiest (for all of us actively participating here) and time-proven way. What did surprise me a bit is that "only" Committers answered a question that I thought may be of wider interest, e.g. also that of users and/or folks not regularly on GH. Without any such "wider" feedback I think we can close this here, though.
@Anton Arapov @Jon Ericson Am I wrong gaining the impression that these community-based discussions are apparently not bringing in diverse voices, e.g., those of users and/or not-GH-bound participants? If this is because they're not informed about the existence of this venue, not technically invited, or just plainly not interested I cannot know of course. Maybe worth while some thoughts or "plenary" questions at the upcoming OpenSSL conference?
Only question remaining for me here and now: How (by whom?) to close this topic for good? Or shall this be left "lingering"? If so, for how long?
Dmitry Belyavsky · Wed 24 Sep 2025 12:01PM
I think the procedure is like a regular PR updating the defaults, probably labeled with the "hold: committers". Also you can raise a proposal as a discussion but PR normally works more effectively