From shawn.hall at nag.com  Tue Mar  5 19:39:56 2019
From: shawn.hall at nag.com (Shawn Hall)
Date: Tue, 5 Mar 2019 18:39:56 +0000
Subject: [gnutls-help] GnuTLS performance on slower devices
Message-ID: <AM4PR05MB32346AB500D54A969435A03C99720@AM4PR05MB3234.eurprd05.prod.outlook.com>

Hi,

One of our customers uses TigerVNC for graphical connections to systems.  There are more details here https://github.com/TigerVNC/tigervnc/issues/737, but we've found that on slower devices such as the Microsoft Surface Pro 4 that there was a noticeable slowdown when encryption is enabled.  In talking to the TigerVNC developers, we've found that this slowdown is due to some fundamental parts of GnuTLS such a memory allocation and buffer management.

Is there any work in progress or planned that would improve GnuTLS performance on slower devices?

Thanks,
Shawn
This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20190305/bdefcea0/attachment-0001.html>

From dank at kegel.com  Tue Mar  5 20:11:03 2019
From: dank at kegel.com (Dan Kegel)
Date: Tue, 5 Mar 2019 11:11:03 -0800
Subject: [gnutls-help] GnuTLS performance on slower devices
In-Reply-To: <AM4PR05MB32346AB500D54A969435A03C99720@AM4PR05MB3234.eurprd05.prod.outlook.com>
References: <AM4PR05MB32346AB500D54A969435A03C99720@AM4PR05MB3234.eurprd05.prod.outlook.com>
Message-ID: <CAPF-yOawdK2DOFsFZWYY_s=Sxdi9LXcevfb3S093Mdz=6LiEBw@mail.gmail.com>

I added a question about the affected cpu type(s) at
https://github.com/TigerVNC/tigervnc/issues/737

On Tue, Mar 5, 2019 at 10:55 AM Shawn Hall <shawn.hall at nag.com> wrote:
>
> Hi,
>
>
>
> One of our customers uses TigerVNC for graphical connections to systems.  There are more details here https://github.com/TigerVNC/tigervnc/issues/737, but we?ve found that on slower devices such as the Microsoft Surface Pro 4 that there was a noticeable slowdown when encryption is enabled.  In talking to the TigerVNC developers, we?ve found that this slowdown is due to some fundamental parts of GnuTLS such a memory allocation and buffer management.
>
>
>
> Is there any work in progress or planned that would improve GnuTLS performance on slower devices?
>
>
>
> Thanks,
>
> Shawn
>
>
>
> Disclaimer
>
> Please see our Privacy Notice for information on how we process personal data.
>
> This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.
>
> _______________________________________________
> Gnutls-help mailing list
> Gnutls-help at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-help


From mail at maciej.szmigiero.name  Mon Mar 11 00:02:42 2019
From: mail at maciej.szmigiero.name (Maciej S. Szmigiero)
Date: Mon, 11 Mar 2019 00:02:42 +0100
Subject: [gnutls-help] gnutls_memset: use explicit_bzero
Message-ID: <9200497b-a074-2153-e422-8d08d0099e7a@maciej.szmigiero.name>

> That is, use the glibc function when available and the second
> parameter is zero.
> 
> Resolves #230
> 
> Signed-off-by: Nikos Mavrogiannopoulos <nmav at redhat.com>
> ---(..)
> --- a/lib/safe-memfuncs.c
> +++ b/lib/safe-memfuncs.c
> @@ -33,14 +30,18 @@
>   * This function will operate similarly to memset(), but will
>   * not be optimized out by the compiler.
>   *
> - * Returns: void.
> - *
>   * Since: 3.4.0
>   **/
>  void gnutls_memset(void *data, int c, size_t size)
>  {
> -	volatile unsigned volatile_zero = 0;
> +	volatile unsigned volatile_zero;
>  	volatile char *vdata = (volatile char*)data;
> +#ifdef HAVE_EXPLICIT_BZERO
> +	if (c == 0) {
> +		explicit_bzero(data, size);

Shouldn't the function return here?

Because otherwise it is doing the zeroing twice:
first time via explicit_bzero(),
second time via a volatile trick below.

> +	}
> +#endif
> +	volatile_zero = 0;
>  
>  	/* This is based on a nice trick for safe memset,
>  	 * sent by David Jacobson in the openssl-dev mailing list.

Maciej


From a.dalbo at adbglobal.com  Tue Mar 12 14:13:46 2019
From: a.dalbo at adbglobal.com (Andrea Dal Bo)
Date: Tue, 12 Mar 2019 13:13:46 +0000
Subject: [gnutls-help] about ecnrypting pkts with lenght 0
Message-ID: <AM6PR10MB2582B68C4C818EFD5450D231F2490@AM6PR10MB2582.EURPRD10.PROD.OUTLOOK.COM>

Hi,
recently we moved from gnults 2.13.23 to gnutls 3.6.5.
By doing this I encountered an issue with applications using the library. In fact it happens that the our TR-069 agent is sending pkts over https by means of gnutls_record_send. It might happens that gnutls_record_send is called with data_size=0.  This was accepted in the older gnutls 2.13.23.
With gnutls 3.6.5 it is not. In fact gnutls_record_send calls gnutls_record_send2 with pad=0, and subsequently _gnutls_send_tlen_int  that verifies that if both data_size and pad are 0 returns GNUTLS_E_INVALID_REQUEST (record.c line 492).
I tried to modify the application to add a padding>=1 in case of data_size=0 by calling  gnutls_record_can_use_length_hiding. In fact even if this function was returning 1, the subsequent call of gnutls_record_send2 was still returning GNUTLS_E_INVALID_REQUEST. In fact the discrimination was that tls1.3 handshake semantics was set to false. That is a bit misleading, IMHO.
Can you explain the reason for that?
Moreover why this restriction on the data_size length has been added to?
Thanks

Andrea

[https://www.adbglobal.com/wp-content/uploads/adb.png]
adbglobal.com<https://www.adbglobal.com>
This message (including any attachments) may contain confidential, proprietary, privileged and/or private information. The information is intended for the use of the individual or entity designated above. If you are not the intended recipient of this message, please notify the sender immediately, and delete the message and any attachments. Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is STRICTLY PROHIBITED.
Please note that ADB protects your privacy. Any personal information we collect from you is used in accordance with our Privacy Policy<https://www.adbglobal.com/privacy-policy/> and in compliance with applicable European data protection law (Regulation (EU) 2016/679, General Data Protection Regulation) and other statutory provisions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20190312/4cad4b3d/attachment.html>

From rick at openfortress.nl  Tue Mar 26 21:19:02 2019
From: rick at openfortress.nl (Rick van Rein)
Date: Tue, 26 Mar 2019 21:19:02 +0100
Subject: [gnutls-help] Cert in DER, a pleasant surprise...?
Message-ID: <5C9A8936.60800@openfortress.nl>

Hi,

I read in your docs on "gnutls_certificate_get_crt_raw ()" that it
intends to "return the DER encoded certificate of the server".  That
raises a few questions.

1.
Did you mean to return the _peer_ certificate, or always the _server_
certificate?

2.
When the certificate is not DER-encoded, do you recode it?  That would
be quite useful!  This is not a PEM-or-DER question but BER-or-DER.  The
TBSCertificate needs to be canonical so DER, but the Certificate around
it may be BER, as specified in .  Not sure everyone knows this... and
having it repackaged would be pleasant to stop bugs caused by it.

I'm going by RFC 3280/5280, and RFC 8446 details DER for every
CertificateEntry, but I don't believe that RFC 5246 does the same?

Sorry for the attention of detail, it might be a security thing...


Cheers,
 -Rick


From n.mavrogiannopoulos at gmail.com  Wed Mar 27 08:13:05 2019
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 27 Mar 2019 08:13:05 +0100
Subject: [gnutls-help] Cert in DER, a pleasant surprise...?
In-Reply-To: <5C9A8936.60800@openfortress.nl>
References: <5C9A8936.60800@openfortress.nl>
Message-ID: <aa2a993a200d0a44158204092a45efec1cd2516a.camel@gmail.com>

On Tue, 2019-03-26 at 21:19 +0100, Rick van Rein wrote:
> Hi,
> 
> I read in your docs on "gnutls_certificate_get_crt_raw ()" that it
> intends to "return the DER encoded certificate of the server".  That
> raises a few questions.
> 
> 1.
> Did you mean to return the _peer_ certificate, or always the _server_
> certificate?

Hi,
 This returns the certificate as in the credentials structure.

> 2.
> When the certificate is not DER-encoded, do you recode it?  That
> would be quite useful! This is not a PEM-or-DER question but BER-or-
> DER.  The
> TBSCertificate needs to be canonical so DER, but the Certificate
> around
> it may be BER, as specified in .  Not sure everyone knows this... and
> having it repackaged would be pleasant to stop bugs caused by it.

I'd treat that as an implementation detail. We used to always DER-re-
encode certificates, but that caused problems interoperating with
golang applications which used to generate certificates not following
DER very strictly, thus gnutls was breaking the signatures for them.

regards,
Nikos




From n.mavrogiannopoulos at gmail.com  Wed Mar 27 08:23:10 2019
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 27 Mar 2019 08:23:10 +0100
Subject: [gnutls-help] about ecnrypting pkts with lenght 0
In-Reply-To: <AM6PR10MB2582B68C4C818EFD5450D231F2490@AM6PR10MB2582.EURPRD10.PROD.OUTLOOK.COM>
References: <AM6PR10MB2582B68C4C818EFD5450D231F2490@AM6PR10MB2582.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <93536717e553a15866a6091942685a4bc1044193.camel@gmail.com>

On Tue, 2019-03-12 at 13:13 +0000, Andrea Dal Bo wrote:
> Hi,
> recently we moved from gnults 2.13.23 to gnutls 3.6.5.
> By doing this I encountered an issue with applications using the
> library. In fact it happens that the our TR-069 agent is sending pkts
> over https by means of gnutls_record_send. It might happens that
> gnutls_record_send is called with data_size=0.  This was accepted in
> the older gnutls 2.13.23.
> With gnutls 3.6.5 it is not. In fact gnutls_record_send calls
> gnutls_record_send2 with pad=0, and subsequently
> _gnutls_send_tlen_int  that verifies that if both data_size and pad
> are 0 returns GNUTLS_E_INVALID_REQUEST (record.c line 492).

Hi,
 What is your goal with this behavior? The library tries to protect
against incorrect use of it, and sending zero-byte packets was probably
one of them (they are used for specific purposes in the protocol and
can confuse the peer).

> I tried to modify the application to add a padding>=1 in case of
> data_size=0 by calling  gnutls_record_can_use_length_hiding. In fact
> even if this function was returning 1, the subsequent call of
> gnutls_record_send2 was still returning GNUTLS_E_INVALID_REQUEST. In
> fact the discrimination was that tls1.3 handshake semantics was set
> to false. That is a bit misleading, IMHO.  

I am not sure I understand this, what do you mean here?

btw. if you think that's a bug it is easier to bring on the issue
tracker (I do not follow the help list much, and I think that's the
same with other developers).

regards,
Nikos




From nmav at gnutls.org  Wed Mar 27 08:07:57 2019
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 27 Mar 2019 08:07:57 +0100
Subject: [gnutls-help] gnutls 3.6.7
Message-ID: <9ced968063d37fa87631b69155a8fb2e911e149c.camel@gnutls.org>

Hello, 
 I've just released gnutls 3.6.7. This is a bug fix and security
release on the stable 3.6.x branch. 

I'd like to thank everyone who contributed in this release:
Alon Bar-Lev, Anderson Toshiyuki Sasaki, Andreas Metzler, Bas van
Schaik, Daiki Ueno, Dmitry Eremin-Solenikov, Hugo Beauz?e-Luyssen,
Ke Zhao, R. Andrew Bailey, Steve Lhomme, and Tim R?hsen.

The applicable security advisory GNUTLS-SA-2019-03-27 will be made
available at:
https://www.gnutls.org/security-new.html

The detailed list of changes follows; they can be seen in more detail
in our milestone tracker:
https://gitlab.com/gnutls/gnutls/milestones/19

Changes
=======

* Version 3.6.7 (released 2019-03-27)

** libgnutls, gnutls tools: Every gnutls_free() will automatically set
   the free'd pointer to NULL. This prevents possible use-after-free and
   double free issues. Use-after-free will be turned into NULL dereference.
   The counter-measure does not extend to applications using gnutls_free().

** libgnutls: Fixed a memory corruption (double free) vulnerability in the
   certificate verification API. Reported by Tavis Ormandy; addressed with
   the change above. [GNUTLS-SA-2019-03-27, #694]

** libgnutls: Fixed an invalid pointer access via malformed TLS1.3 async messages;
   Found using tlsfuzzer. [GNUTLS-SA-2019-03-27, #704]

** libgnutls: enforce key usage limitations on certificates more actively.
   Previously we would enforce it for TLS1.2 protocol, now we enforce it
   even when TLS1.3 is negotiated, or on client certificates as well. When
   an inappropriate for TLS1.3 certificate is seen on the credentials structure
   GnuTLS will disable TLS1.3 support for that session (#690).

** libgnutls: the default number of tickets sent under TLS 1.3 was increased to
   two. This makes it easier for clients which perform multiple connections
   to the server to use the tickets sent by a default server.

** libgnutls: enforce the equality of the two signature parameters fields in
   a certificate. We were already enforcing the signature algorithm, but there
   was a bug in parameter checking code.

** libgnutls: fixed issue preventing sending and receiving from different
   threads when false start was enabled (#713).

** libgnutls: the flag GNUTLS_PKCS11_OBJ_FLAG_LOGIN_SO now implies a writable
   session, as non-writeable security officer sessions are undefined in PKCS#11
   (#721).

** libgnutls: no longer send downgrade sentinel in TLS 1.3.
   Previously the sentinel value was embedded to early in version
   negotiation and was sent even on TLS 1.3. It is now sent only when
   TLS 1.2 or earlier is negotiated (#689).

** gnutls-cli: Added option --logfile to redirect informational messages output.

** API and ABI modifications:
No changes since last version.


Getting the Software
====================

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>;.  A list of GnuTLS mirrors can
be found at <http://www.gnutls.org/download.html>;.

Here are the XZ compressed sources:

  https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.7.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

  https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.7.tar.xz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos




From n.mavrogiannopoulos at gmail.com  Wed Mar 27 08:24:58 2019
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 27 Mar 2019 08:24:58 +0100
Subject: [gnutls-help] gnutls_memset: use explicit_bzero
In-Reply-To: <9200497b-a074-2153-e422-8d08d0099e7a@maciej.szmigiero.name>
References: <9200497b-a074-2153-e422-8d08d0099e7a@maciej.szmigiero.name>
Message-ID: <473b5c084ff1d7679e00d1b8c51cc5bbb5bb47a8.camel@gmail.com>

On Mon, 2019-03-11 at 00:02 +0100, Maciej S. Szmigiero wrote:
> > That is, use the glibc function when available and the second
> > parameter is zero.
> > 
> > Resolves #230
> > 
> > Signed-off-by: Nikos Mavrogiannopoulos <nmav at redhat.com>
> > ---(..)
> > --- a/lib/safe-memfuncs.c
> > +++ b/lib/safe-memfuncs.c
> > @@ -33,14 +30,18 @@
> >   * This function will operate similarly to memset(), but will
> >   * not be optimized out by the compiler.
> >   *
> > - * Returns: void.
> > - *
> >   * Since: 3.4.0
> >   **/
> >  void gnutls_memset(void *data, int c, size_t size)
> >  {
> > -	volatile unsigned volatile_zero = 0;
> > +	volatile unsigned volatile_zero;
> >  	volatile char *vdata = (volatile char*)data;
> > +#ifdef HAVE_EXPLICIT_BZERO
> > +	if (c == 0) {
> > +		explicit_bzero(data, size);
> 
> Shouldn't the function return here?
> 
> Because otherwise it is doing the zeroing twice:
> first time via explicit_bzero(),
> second time via a volatile trick below.

You are right. Would you like to send a merge request fixing that?

regards,
Nikos




From n.mavrogiannopoulos at gmail.com  Wed Mar 27 08:28:44 2019
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 27 Mar 2019 08:28:44 +0100
Subject: [gnutls-help] GnuTLS performance on slower devices
In-Reply-To: <AM4PR05MB32346AB500D54A969435A03C99720@AM4PR05MB3234.eurprd05.prod.outlook.com>
References: <AM4PR05MB32346AB500D54A969435A03C99720@AM4PR05MB3234.eurprd05.prod.outlook.com>
Message-ID: <d9c873c2ec1556fad7186b17e878d07f0ae2b237.camel@gmail.com>

On Tue, 2019-03-05 at 18:39 +0000, Shawn Hall wrote:
> Hi,
>  
> One of our customers uses TigerVNC for graphical connections to
> systems.  There are more details here 
> https://github.com/TigerVNC/tigervnc/issues/737, but we?ve found that
> on slower devices such as the Microsoft Surface Pro 4 that there was
> a noticeable slowdown when encryption is enabled.  In talking to the
> TigerVNC developers, we?ve found that this slowdown is due to some
> fundamental parts of GnuTLS such a memory allocation and buffer
> management.
>  
> Is there any work in progress or planned that would improve GnuTLS
> performance on slower devices?

I was never aware of any such problem with memory allocation and buffer
management on slower devices. What I believe is more likely is that
crypto in nettle library is not optimized for these platforms. There
are certain improvements discussed on the nettle for specific platforms
on its mailing list.

regards,
Nikos




From rick at openfortress.nl  Wed Mar 27 09:01:29 2019
From: rick at openfortress.nl (Rick van Rein)
Date: Wed, 27 Mar 2019 09:01:29 +0100
Subject: [gnutls-help] Cert in DER, a pleasant surprise...?
In-Reply-To: <aa2a993a200d0a44158204092a45efec1cd2516a.camel@gmail.com>
References: <5C9A8936.60800@openfortress.nl>
 <aa2a993a200d0a44158204092a45efec1cd2516a.camel@gmail.com>
Message-ID: <5C9B2DD9.1080007@openfortress.nl>

Hi,

> We used to always DER-re-
> encode certificates, but that caused problems interoperating with
> golang applications which used to generate certificates not following
> DER very strictly, thus gnutls was breaking the signatures for them.

Liberal in what you accept, I see.  I took a similar approach with
Quick DER, which accepts almost all BER forms as well.

They are breaking standards however, and it has me concerned that this was not debugged in the Go code.  Even though I can even read the RFCs to say that the TBSCertificate may be encoded differently (including JER) the signature itself must be computed over de DER form.  Packing a certificate into JER might actually be useful to some use cases, but it would break on Go certificates, apparantly.

I am wondering if this might create a single-language ecosystem that won't work with other applications.  I would have stopped Google at this point.  It is a good reason to not use Go, or at least its certificate "support" code.

I would have started a debugging process in Go... and perhaps given them some leeway for a few upcoming releases.

-Rick


From n.mavrogiannopoulos at gmail.com  Wed Mar 27 09:08:51 2019
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 27 Mar 2019 09:08:51 +0100
Subject: [gnutls-help] Cert in DER, a pleasant surprise...?
In-Reply-To: <5C9B2DD9.1080007@openfortress.nl>
References: <5C9A8936.60800@openfortress.nl>
 <aa2a993a200d0a44158204092a45efec1cd2516a.camel@gmail.com>
 <5C9B2DD9.1080007@openfortress.nl>
Message-ID: <ff3423e1eb6e79df6596e76a66ad0dbd7f810a55.camel@gmail.com>

On Wed, 2019-03-27 at 09:01 +0100, Rick van Rein wrote:
> Hi,
> 
> > We used to always DER-re-
> > encode certificates, but that caused problems interoperating with
> > golang applications which used to generate certificates not
> > following
> > DER very strictly, thus gnutls was breaking the signatures for
> > them.
> 
> Liberal in what you accept, I see.  I took a similar approach with
> Quick DER, which accepts almost all BER forms as well.
> 
> They are breaking standards however, and it has me concerned that
> this was not debugged in the Go code.  Even though I can even read
> the RFCs to say that the TBSCertificate may be encoded differently
> (including JER) the signature itself must be computed over de DER
> form.  Packing a certificate into JER might actually be useful to
> some use cases, but it would break on Go certificates, apparantly.
> 
> I am wondering if this might create a single-language ecosystem that
> won't work with other applications.  I would have stopped Google at
> this point.  It is a good reason to not use Go, or at least its
> certificate "support" code.
> 
> I would have started a debugging process in Go... and perhaps given
> them some leeway for a few upcoming releases.

The issue was not something complex, but with the SET ordering in DER
rules; it was treated as bug: (though not yet resolved)
https://github.com/golang/go/issues/24254

regards,
Nikos




From mail at maciej.szmigiero.name  Thu Mar 28 23:08:07 2019
From: mail at maciej.szmigiero.name (Maciej S. Szmigiero)
Date: Thu, 28 Mar 2019 23:08:07 +0100
Subject: [gnutls-help] gnutls_memset: use explicit_bzero
In-Reply-To: <473b5c084ff1d7679e00d1b8c51cc5bbb5bb47a8.camel@gmail.com>
References: <9200497b-a074-2153-e422-8d08d0099e7a@maciej.szmigiero.name>
 <473b5c084ff1d7679e00d1b8c51cc5bbb5bb47a8.camel@gmail.com>
Message-ID: <158964ce-c6a8-1a16-b2a7-46bbeaba3fec@maciej.szmigiero.name>

On 27.03.2019 08:24, Nikos Mavrogiannopoulos wrote:
> On Mon, 2019-03-11 at 00:02 +0100, Maciej S. Szmigiero wrote:
>>> That is, use the glibc function when available and the second
>>> parameter is zero.
>>>
>>> Resolves #230
>>>
>>> Signed-off-by: Nikos Mavrogiannopoulos <nmav at redhat.com>
>>> ---(..)
>>> --- a/lib/safe-memfuncs.c
>>> +++ b/lib/safe-memfuncs.c
>>> @@ -33,14 +30,18 @@
>>>   * This function will operate similarly to memset(), but will
>>>   * not be optimized out by the compiler.
>>>   *
>>> - * Returns: void.
>>> - *
>>>   * Since: 3.4.0
>>>   **/
>>>  void gnutls_memset(void *data, int c, size_t size)
>>>  {
>>> -	volatile unsigned volatile_zero = 0;
>>> +	volatile unsigned volatile_zero;
>>>  	volatile char *vdata = (volatile char*)data;
>>> +#ifdef HAVE_EXPLICIT_BZERO
>>> +	if (c == 0) {
>>> +		explicit_bzero(data, size);
>>
>> Shouldn't the function return here?
>>
>> Because otherwise it is doing the zeroing twice:
>> first time via explicit_bzero(),
>> second time via a volatile trick below.
> 
> You are right. Would you like to send a merge request fixing that?

While I don't have a gitlab account to open a merge request there
I have attached a patch made by git-format-patch.
Hope this way will work, too.

> regards,
> Nikos

Thanks,
Maciej
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-gnutls_memset-calling-explicit_bzero-is-enough-to-ze.patch
Type: text/x-patch
Size: 868 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20190328/b6f02194/attachment.bin>