Re: ALPN support for GnuTLS connections

[Robert Pluim]

>>>>> On Tue, 15 Oct 2024 09:06:49 +0200, Eric Marsden 
>>>>> <eric.marsden@risk-engineering.org> said:

    Eric> On 14/10/2024 11:22, Robert Pluim wrote:
    >>>>>>> On Sat, 12 Oct 2024 11:30:41 +0200, Eric Marsden 
<eric.marsden@risk-engineering.org> said:
    Eric> (1) It would be useful for elisp code to be able to determine whether
    Eric> Emacs has ALPN support. The elisp code will generally know that the
    Eric> service it's connecting to requires ALPN, and it would be useful to be
    Eric> able to inform the user that they should upgrade Emacs, instead of
    Eric> getting a generic "connection failed" error. The C preprocessor test
    Eric> HAVE_GNUTLS_ALPN_SET_PROTOCOLS  isn't visible from elisp, nor is (I
    Eric> think?) the binding to gnutls_alpn_set_protocols. This might also be
    Eric> useful for other features such as the AEAD support. Perhaps a function
    Eric> such as gnutls-feature-available-p(:alpn) ?
    >> 
    >> `gnutls-available-p' returns a list of available TLS features, we can put
    >> "alpn" in there. AEAD is already there.
    Eric> OK, that sounds good to me, thanks.

    >> Yes, in order to palliate servers not following the requirement to be
    >> strict, the recommendation is for the client to be strict. I donʼt
    >> mind that, although we should add a way to turn it off. Perhaps an
    >> ":alpn-flags" parameter with symbols for the two current flags, plus
    >> one that means "zero".
    Eric> Also sounds good.

Except that itʼs not working. Either GNUTLS_ALPN_MANDATORY is a
server-only flag or Iʼm using it wrong. More debugging required.

Robert
--