What were you trying to do that didn't work?

gnutls-cli --resume --early-data=... against a gnutls server

What is the impact of this issue to you?

I'm sad at how it used to work, how it works now and how it might get fixed in the future, all at once.

Please provide the package NVR for which the bug is seen:

gnutls-3.8.9-9.el10

How reproducible is this bug?:

reliably

Steps to reproduce

1. spin up a gnutls server
2. gnutls-cli --resume --early-data=... against it
3. get an error sending early data

Expected results

Resumed connection sends early data.

max_early_data_size access pattern before the change:

  gnutls_init initializes it to 4294967295 (UINT32_MAX)
  parse_nst_extension sets it to 16384

  gnutls_init initializes it to 4294967295
  gnutls_record_recv_early_data checks it
  gnutls_record_recv_early_data proceeds successfully

max_early_data_size access pattern after the change:

Then, after https://gitlab.com/gnutls/gnutls/-/merge_requests/1906

  gnutls_init initializes it to 0
  parse_nst_extension sets it to 16384

  gnutls_init initializes it to 0
  gnutls_record_recv_early_data checks it
  gnutls_record_recv_early_data fails with error sending early data

Proposed solutions:

In https://gitlab.com/gnutls/gnutls/-/merge_requests/1936, the gnutls-cli is modified to preserve the data between sessions itself, which, IMO, only masks the problem by shifting the burden of responsibility to the applications.

The idea of preserving extension data from https://gitlab.com/gnutls/gnutls/-/issues/1667 sounds more interesting.