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

Thierry Quemerais tquemerais at awox.com
Mon Mar 16 09:39:33 CET 2015

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.


-----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
* 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.


More information about the Gnutls-help mailing list