[gnutls-help] GNU TLS and extensions/supplemental data

[Thierry Quemerais]

Hi Nikos,

I got your point.

I will change that and I will do what you suggested:  Create an API gnutls_ext_register that receive in parameters all what is needed.
I will also include a test file for your test suite and I will try to separate this patch as 3 different patches.

Regards,
Thierry

-----Original Message-----
From: n.mavrogiannopoulos at gmail.com [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos
Sent: Friday, March 13, 2015 4:45 PM
To: Thierry Quemerais
Cc: gnutls-help at lists.gnutls.org
Subject: Re: [gnutls-help] GNU TLS and extensions/supplemental data

On Fri, Mar 13, 2015 at 2:53 PM, Thierry Quemerais <tquemerais at awox.com> wrote:
> Hi Nikos,
>
> Thank you for your reply.
>
> Please find attached to this Email, the patch I made to achieve my goal.
> For your information, I also found an issue in GNUTLS which does not handle supplemental data type > 255.
> This fix is included in this patch:
> -                       buf->data[sizepos] = 0;
> -                       buf->data[sizepos + 1] = p->type;
> +                       buf->data[sizepos] = (p->type >> 8) & 0xFF;
> +                       buf->data[sizepos + 1] = (p->type) & 0xFF;

Applied separately.

> To achieve my goal :
>         I changed the way supplemental callback are stored. (gnutls_supplemental.c)
>         I moved extension en supplemental structure to gnutls.h header.  (gnutls_supplemental_entry, extension_entry_st)
>         I created an opaque struct for strings (typedef struct gnutls_buffer gnutls_buffer_st;) and I added a function to append data in this buffer (Used by extension/supplemental callbacks).

Thank you. I like the patch, it is pretty simple and straightforward.
My main objection is the export of gnutls_ext_register structure,
which will require ABI break in case we add anything there. Why not
keep _gnutls_ext_register() as is, and then export a
gnutls_ext_register() which receives everything needed in the current
structure as parameters? The same for gnutls_supplemental_entry... The
risk of this structure changing is lower, but better safe than sorry.

Some more, but minor comments.
* Would it be possible to submit the a patch from git, and use the
--signoff flag (as well as send the DCO - see
http://www.gnutls.org/devel.html)
* It would be convenient for debugging to split the patch into two,
one for the extensions and on for the supplemental
* In extension_entry_st you use "short type". I think simply using an
int or unsigned int would be better.
* Do you have some small test programs to use in our test suite for
this API? That would ensure that the API you add now remains unbroken
over releases.

regards,
Nikos