[gnutls-help] Regression bug between 2.x and 3.2?

[Nikos Mavrogiannopoulos]

On Mon, 2014-06-16 at 14:54 +0000, Lavrentiev, Anton (NIH/NLM/NCBI) [C]
wrote:
> > From that description I think that this is pretty much expected. A call
> > to gnutls_record_send() can be interrupted, and had to be called again
> > (I believe that was the case in all gnutls versions). If that's not
> > clear from the documentation please let me know what could be improved.
> 
> Here's the problem:  there was no interruption, there was a short write.
> Previous version of GNUTLS tolerated that by calling the push callback
> once again, and again, and again, giving up only when nothing _at all_
> was written (-1 returned).  Current version bails out immediately.
> This is a change in behavior, which is not backward compatible.
> The code in gnutls_buffers.c has changed significantly:  it was presumably
> necessary to accommodate a vector write operation (writev), and could have
> resulted in the inadvertent change for the plain push.

Hello Anton,
 Indeed. However, note that this change is backwards compatible. The
push function doesn't need to change at all. Whether gnutls calls it
once or twice on short reads is an internal behavior of gnutls, you
shouldn't have depended on.

What is the only requirement of the gnutls API is that the caller of
gnutls_record_send(), retries the call if interrupted with
GNUTLS_E_AGAIN or GNUTLS_E_INTERRUPTED, that was always the case. If
that is followed it wouldn't matter whether gnutls would retry the push
function or not. Does making that change address your issue?

> Anyhow, the push callback is documented to be a send()-like thing.
> Which means it is allowed to write fewer bytes than it was requested to,
> and that does not constitute an error.  Previous GNUTLS version treated
> that exactly so, by re-trying the write until unsuccessful (and advancing
> with writes, most of the time). 

Yes, that's the only requirement of the push callback. However, the way
gnutls will call it, is an internal matter that may change at any time
(it's not part of the API nor described anywhere).

regards,
Nikos