[gnutls-devel] GnuTLS | Soft-disabling configuration capabilities should match the hard-disabling ones (#1172)

[Read-only notification of GnuTLS library development activities]

Alexander Sosedkin commented:


So, the effective configuration now, with a config specifying "hard-disabled" and "config-priority" is:
* for non-TLS: "everything - hard-disabled",
* for TLS not using `@SYSTEM`: "_priority_",
* for TLS using `@SYSTEM:extra-priority`: "config-priority +- _extra-priority_ - hard-disabled".

And what we're aiming for given a config that specifies "soft-disabled", "hard-disabled" and "config-priority":
* for non-TLS: "everything - soft-disabled +- _new-api_ - hard-disabled",
* for TLS not using @SYSTEM: "_priority_ +- _new-api_",
* for TLS using @SYSTEM:extra-priority: "config-priority - soft-disabled +- _extra-priority_ +- _new-api_ - hard-disabled".

(italics signify what's under the application control)

Questions:
* did I get your proposal right?
* do we want new API to affect TLS or not? why?
* will we have everything soft-disabled reenableable with either priority strings or new-api?
* will we have priority-string-format keywords for everything, so that a TLS app could forego new-api and only use priority string?
* if we will have priority-string keywords for everything, can we simplify it somehow? The "priority - soft-disabled +- _extra-priority_ +- _new-api_ - hard-disabled" might be not that hard to merge, but sounds hard to comprehend.
* how orthogonal are new-api and adding soft-disablement?


And now for something completely different: maybe my original request is misguided. Now I'm not sure why vendors go the disabling way at all (https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/issues/22). Maybe we should do soft-enabling instead, for writing future-proof config files that don't change effective configuration on gnutls adding new algorithms? Or allow both with smth like `default=everything / default=nothing`?

This is hard =)

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1172#note_530521992
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/20210316/26fa13bd/attachment.html>