[gnutls-devel] GnuTLS | key_update: rework the rekeying logic (!1990)

[Read-only notification of GnuTLS library development activities]

Daniel P_ Berrangé commented: https://gitlab.com/gnutls/gnutls/-/merge_requests/1990#note_2643460573


Yes, while this MR fixes the stated bug, it also introduces a new regression.

In QEMU's migration flow, we have massive data volumes in one direction, and very very tiny data in the other direction. So with this MR applied, on the client side QEMU, GNUTLS will repeatedly initiate rekeying of the sending keys, but will never see a request from the server for rekey of the receiving key.

When GNUTLS tries to rekey the sending key for the 15th time, it will return `GNUTLS_E_INVALID_REQUEST` from `gnutls_record_send()`.

What is failing is the `epoch_get_slot` function

```
Epoch 18 out of range (idx: 16, max: 16)
```

IIUC, this suggests that `_gnutls_epoch_gc` is no longer working correctly, now that this MR has split the rekeying of sending vs receiving keys,  when you have very asymmetric data flows.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1990#note_2643460573
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/20250722/92e0c853/attachment.html>