[gnutls-devel] GnuTLS | priority: support allowlisting in configuration file (!1427)

[Read-only notification of GnuTLS library development activities]

Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1427 was reviewed by Alexander Sosedkin

--
  
Alexander Sosedkin started a new discussion on doc/cha-config.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_745273038

> +listed below in the @code{[overrides]} section.  As the allowlisting
> +mode is mutually exclusive to the blocklisting mode, the options
> +listed above for the blocklisting mode is forbidden in the

s/is/are/

--
  
Alexander Sosedkin started a new discussion on doc/cha-config.texi: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427#note_745273040

> +configuration file is generated by support tool distributed by the
> +operating systems, such as
> + at uref{https://gitlab.com/redhat-crypto/fedora-crypto-policies/,crypto-policies}.

Oh, if only our tools possessed innate understanding of algorithm interdependencies =)

Alternative phrasing suggestion: "Allowlisting configuration mode is intended to be used by the operating system vendors that prefer laying out the library defaults exhaustively instead on depending on gnutls presets, such as NORMAL. Applications are then expected to optionally disable or enable only select a subset algorithms on top of the vendor-provided configuration." Clearer motivation for the vendors, less sounding like library users need to start looking for config-generation tools.


-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427
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/20211126/70ec7da3/attachment.html>