[gnutls-devel] GnuTLS | gnutls_record_send() fails with GNUTLS_E_INVALID_REQUEST (#823)

[Development of GNU's TLS library]

Michael Catanzaro commented:


> As many applications set `gnutls_transport_set_pull_timeout_function` anyway, an issue like that may not have been noticed. Could that be the case here? (does glib-networking set the pull timeout?)

Hm, this is really weird, because we do set the pull timeout func, always, since glib-networking 2.56. We do it right after setting the normal pull func, in g_tls_connection_gnutls_initable_init(). The only way they could ever not be set is if initialization fails, in which case g_tls_connection_new() will actually return NULL instead of a GTlsConnection, so there's no way applications could try to use it. And there's no way one but not the other could ever be set, because they're always set immediately after the other. The code looks like this:

```
  gnutls_transport_set_push_function (priv->session,
                                      g_tls_connection_gnutls_push_func);
  gnutls_transport_set_pull_function (priv->session,
                                      g_tls_connection_gnutls_pull_func);
  gnutls_transport_set_pull_timeout_function (priv->session,
                                              g_tls_connection_gnutls_pull_timeout_func);
```

So something strange must be going wrong for GnuTLS to think we haven't set that func.

@gtrentalancia is it possible you're using glib-networking older than 2.56? That would be really weird if you have GnuTLS 3.6, but that's my only guess here. GnuTLS 3.6 is not compatible with older versions of glib-networking.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/823#note_222212337
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/20190925/fcb84225/attachment-0001.html>