[gnutls-devel] GnuTLS | Draft: lib/priority: add a [includes] section and file-optional/file-required keys (!1849)

[Read-only notification of GnuTLS library development activities]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20240718/c5dfa009/attachment-0001.html>