Daiki Ueno commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1849#note_2004694033 A couple of questions if we go with that design: - Is `system-priority-directory`/`GNUTLS_SYSTEM_PRIORITY_DIRECTORY` mutually exclusive with `system-priority-file`/`GNUTLS_SYSTEM_PRIORITY_FILE`? - What is the actual behavior of merging multiple configurations? - What happens if there is a configuration option with a same key: would it be overridden, the previous value wins, or even the behavior itself is controllable? Before jumping in on the design and implementation, I would suggest that we should clarify the use-cases. For example: - The default configuration file (provided by the distro) doesn't enable KTLS, but I want to enable it in my own configuration file by adding `global.ktls = true` → This is totally fine - The default configuration file still allows SHA-1 for signatures, while it's not recommended. I want to disable it in my own configuration file by adding `insecure-hash = SHA1` → This is fine, but wouldn't work if the default configuration file uses the allowlisting mode (`global.override-mode = allowlist`) - The default configuration file does not allow SHA-1 for signatures, but I want to enable it back in my own configuration file by adding `secure-hash = SHA1` → This needs more consideration, and would only work if the default configuration file uses the allowlisting mode Do you have any specific scenario you want to support with this? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1849#note_2004694033 You're receiving this email because of your account on gitlab.com.
_______________________________________________ Gnutls-devel mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-devel
