[gnutls-devel] GnuTLS | algorithms: ensure _list() exclude non-existing algorithms (!1542)

[Read-only notification of GnuTLS library development activities]

Daiki Ueno commented on a discussion: https://gitlab.com/gnutls/gnutls/-/merge_requests/1542#note_862006221

> Doesn't reintroducing algorithms to the arrays leave them usable?

No. If `--disable-gost` is specified, all the GOST algorithms are compiled out, through conditionals like [this](https://gitlab.com/gnutls/gnutls/-/blob/aa11f1a0f80a039a8dc27912f178443a2b3bd069/lib/nettle/Makefile.am#L77) and the usage is also filtered [out](https://gitlab.com/gnutls/gnutls/-/blob/aa11f1a0f80a039a8dc27912f178443a2b3bd069/lib/nettle/mac.c#L317) internally. Therefore, if one tries to use a GOST algorithm, she will get an unsupported algorithm error, regardless of this and previous MRs.

The problem I try to solve is sorely about the indication whether the GOST algorithms are supported: typically with `gnutls-cli --list`. There are two approaches: one (the previous MR) is to remove the algorithms entirely from the **known** algorithm list, and the other is to filter out the algorithms in the API functions (e.g., `_list`) which are supposed to work on the **supported** algorithm list.

Both have pros and cons but the former approach has a more severe issue: we break the assumption that the functions that works on the **known** algorithm list, such as `gnutls_cipher_get_name`, should never return NULL or error, if the given algorithm ID is defined in `<gnutls/gnutls.h>`. Note that we cannot easily remove GOST algorithm IDs from the public header as it breaks API compatibility.

I believe the ideal situation is:
1. we make a clear distinction between the functions that works on the **known** or the **supported** algorithm list
1. the functions supposed to work on the **known** algorithm list should never return NULL or error for algorithm IDs defined in the public header
1. to check whether an algorithm is **supported**, a helper function is provided to complement (2)

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1542#note_862006221
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/20220303/291fa2ed/attachment.html>