bug#25061: consider adding %COMPAT to default gnutls priority string

[Ted Zlatanov]

On Sat, 02 Dec 2017 19:36:16 +0200 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> Ted, any news on this?  Emacs 26.1 is getting closer to the release,
EZ> so I'd like to see this issue resolved.

I've looked at the code and at the work that Michael has kindly done on
connection-local variables and profiles.

Eli, first, I need to know if I can make large changes (introducing
connection profiles to GnuTLS) this close to the release. If so, I'll
work in emacs-26.

If we can't, I'll do this work for 26.2 and work in master.

To help you and others gauge the extent of the work, here's a summary:

* support connection profiles for processes, not just buffers (only
  buffers are supported today AFAICT). Or maybe only support processes
  with associated buffers. I'm not sure what's best, maybe Michael and
  others can make suggestions.

* only apply connection profiles when the connection is created. Users
  and applications will be responsible for closing the connection and
  reopening it if the profile changes.

* using `connection-local-set-profile-variables' in gnutls.el, create a
  'gnutls-default-profile with today's settings for
  `gnutls-min-prime-bits', `gnutls-trustfiles', `gnutls-verify-error',
  and `gnutls-algorithm-priority', installing it like so

          (connection-local-set-profiles
            nil
            'gnutls-default-profile)

* using `connection-local-set-profile-variables' in gnutls.el, create a
  'gnutls-compatible-profile with `gnutls-algorithm-priority' containing
  "%COMPAT" and any other needed changes to resolve this bug. Note that
  the default profile will be applied first, so this profile will be
  fairly small. The user will then need to do

          (connection-local-set-profiles
            '(:machine "system-that-needs-compatibility")
            'gnutls-compatible-profile)

* apply connection profiles in `open-network-stream',
  `open-gnutls-stream', and `gnutls-negotiate' as needed. The parameters
  will be :machine (host parameter) and :protocol (service parameter).
  Any other parameters such as :user and :application will be used if
  the application passes them in (so a new optional search criteria
  parameter will need to be added).

* add logging to make it clear to the user what profiles are getting
  applied, and what the final variable values are. This may deserve
  special UI if we can integrate it with the NSM (optional work, Lars
  and others can recommend what's best).

* support connection profiles for the network-security-level and other
  NSM variables as well (optional work, Lars and others can recommend
  what's best).

I think this covers what's needed. Let me know your thoughts and I hope
to wrap this up quickly either way.

Ted