From ueno at gnu.org  Fri Sep  2 08:39:01 2022
From: ueno at gnu.org (Daiki Ueno)
Date: Fri, 02 Sep 2022 15:39:01 +0900
Subject: [gnutls-help] gnutls 3.7.7
In-Reply-To: <566DD4CF-C7AD-4DA1-9D3D-98513F07BECE@schamschula.com> (Marius
 Schamschula's message of "Tue, 30 Aug 2022 16:37:51 -0500")
References: <566DD4CF-C7AD-4DA1-9D3D-98513F07BECE@schamschula.com>
Message-ID: <8735da1dru.fsf-ueno@gnu.org>

Hello Marius,

Marius Schamschula <lists at schamschula.com> writes:

> I?m the maintainer of the gnutls package for MacPorts.
>
> Repology just tagged gnutls 3.6.16 as vulnerable.
>
> It seems that the security fix(es) in gnutls 3.7.7 have not been back ported to the 3.6.x
> branch, which is still listed as the stable branch.
>
> The gnutls website suggests all users upgrade to version 3.7.7, even those on the
> stable branch, while 3.7.x has not been declared as the stable branch.
>
> What gives?

I would say we could declare 3.7.x as stable, given the amount of
backward incompatible changes since 3.6.x is limited.  Any thoughts on
that?

If we want to keep 3.6.x, someone would need to invest on updating the
CI infrastructure (either porting the recent changes or switching a
simpler CI configuration for the old branch), which may require
significant effort.

Regards,
-- 
Daiki Ueno


From simon at josefsson.org  Fri Sep  2 08:54:02 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 02 Sep 2022 08:54:02 +0200
Subject: [gnutls-help] gnutls 3.7.7
In-Reply-To: <8735da1dru.fsf-ueno@gnu.org> (Daiki Ueno's message of "Fri, 02
 Sep 2022 15:39:01 +0900")
References: <566DD4CF-C7AD-4DA1-9D3D-98513F07BECE@schamschula.com>
 <8735da1dru.fsf-ueno@gnu.org>
Message-ID: <87bkry5ks5.fsf@latte.josefsson.org>

Daiki Ueno <ueno at gnu.org> writes:

> Hello Marius,
>
> Marius Schamschula <lists at schamschula.com> writes:
>
>> I?m the maintainer of the gnutls package for MacPorts.
>>
>> Repology just tagged gnutls 3.6.16 as vulnerable.
>>
>> It seems that the security fix(es) in gnutls 3.7.7 have not been back ported to the 3.6.x
>> branch, which is still listed as the stable branch.
>>
>> The gnutls website suggests all users upgrade to version 3.7.7, even those on the
>> stable branch, while 3.7.x has not been declared as the stable branch.
>>
>> What gives?
>
> I would say we could declare 3.7.x as stable, given the amount of
> backward incompatible changes since 3.6.x is limited.  Any thoughts on
> that?

Could you release the 3.7.x branch as 3.8.0 and declare that stable?
That would effectively turn all code in 3.7.x (that is still around)
into stable and supported code via the 3.8.x branch.  I'm happy to help,
although it was years since I last did significant work on GnuTLS.

> If we want to keep 3.6.x, someone would need to invest on updating the
> CI infrastructure (either porting the recent changes or switching a
> simpler CI configuration for the old branch), which may require
> significant effort.

The GnuTLS CI takes hours to complete - this seems detrimental to
productivity.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20220902/7232775d/attachment.sig>

From ueno at gnu.org  Fri Sep  2 10:36:56 2022
From: ueno at gnu.org (Daiki Ueno)
Date: Fri, 02 Sep 2022 17:36:56 +0900
Subject: [gnutls-help] gnutls 3.7.7
In-Reply-To: <87bkry5ks5.fsf@latte.josefsson.org> (Simon Josefsson's message
 of "Fri, 02 Sep 2022 08:54:02 +0200")
References: <566DD4CF-C7AD-4DA1-9D3D-98513F07BECE@schamschula.com>
 <8735da1dru.fsf-ueno@gnu.org> <87bkry5ks5.fsf@latte.josefsson.org>
Message-ID: <87y1v2yxxz.fsf-ueno@gnu.org>

Simon Josefsson <simon at josefsson.org> writes:

> Daiki Ueno <ueno at gnu.org> writes:
>
>> Hello Marius,
>>
>> Marius Schamschula <lists at schamschula.com> writes:
>>
>>> I?m the maintainer of the gnutls package for MacPorts.
>>>
>>> Repology just tagged gnutls 3.6.16 as vulnerable.
>>>
>>> It seems that the security fix(es) in gnutls 3.7.7 have not been
>>> back ported to the 3.6.x
>>> branch, which is still listed as the stable branch.
>>>
>>> The gnutls website suggests all users upgrade to version 3.7.7,
>>> even those on the
>>> stable branch, while 3.7.x has not been declared as the stable branch.
>>>
>>> What gives?
>>
>> I would say we could declare 3.7.x as stable, given the amount of
>> backward incompatible changes since 3.6.x is limited.  Any thoughts on
>> that?
>
> Could you release the 3.7.x branch as 3.8.0 and declare that stable?
> That would effectively turn all code in 3.7.x (that is still around)
> into stable and supported code via the 3.8.x branch.

That would be an option and now is probably the time to consider a next
major release as it's been almost two years since 3.7.0.  We currently
follow a bi-monthly release cadence and the next release will be
mid-Sept, so I suggest targeting the next next release (mid-November) at
nearest.  Let's start planning on the milestone[1].

> I'm happy to help, although it was years since I last did significant
> work on GnuTLS.

Thank you!

>> If we want to keep 3.6.x, someone would need to invest on updating the
>> CI infrastructure (either porting the recent changes or switching a
>> simpler CI configuration for the old branch), which may require
>> significant effort.
>
> The GnuTLS CI takes hours to complete - this seems detrimental to
> productivity.

We actually know which jobs are taking hours: "make distcheck" and
cppcheck runs.  Maybe we could turn them off for the stable branch
(gnutls_3_6_x) for now, using the rules keyword[2].

Regards,

Footnotes:
[1]  https://gitlab.com/gnutls/gnutls/-/milestones/30

[2]  https://docs.gitlab.com/ee/ci/yaml/#rules

-- 
Daiki Ueno


From simon at josefsson.org  Fri Sep  2 11:22:58 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 02 Sep 2022 11:22:58 +0200
Subject: [gnutls-help] gnutls 3.7.7
In-Reply-To: <87y1v2yxxz.fsf-ueno@gnu.org> (Daiki Ueno's message of "Fri, 02
 Sep 2022 17:36:56 +0900")
References: <566DD4CF-C7AD-4DA1-9D3D-98513F07BECE@schamschula.com>
 <8735da1dru.fsf-ueno@gnu.org> <87bkry5ks5.fsf@latte.josefsson.org>
 <87y1v2yxxz.fsf-ueno@gnu.org>
Message-ID: <877d2m5dvx.fsf@latte.josefsson.org>

Daiki Ueno <ueno at gnu.org> writes:

> Simon Josefsson <simon at josefsson.org> writes:
>
>> Daiki Ueno <ueno at gnu.org> writes:
>>
>>> Hello Marius,
>>>
>>> Marius Schamschula <lists at schamschula.com> writes:
>>>
>>>> I?m the maintainer of the gnutls package for MacPorts.
>>>>
>>>> Repology just tagged gnutls 3.6.16 as vulnerable.
>>>>
>>>> It seems that the security fix(es) in gnutls 3.7.7 have not been
>>>> back ported to the 3.6.x
>>>> branch, which is still listed as the stable branch.
>>>>
>>>> The gnutls website suggests all users upgrade to version 3.7.7,
>>>> even those on the
>>>> stable branch, while 3.7.x has not been declared as the stable branch.
>>>>
>>>> What gives?
>>>
>>> I would say we could declare 3.7.x as stable, given the amount of
>>> backward incompatible changes since 3.6.x is limited.  Any thoughts on
>>> that?
>>
>> Could you release the 3.7.x branch as 3.8.0 and declare that stable?
>> That would effectively turn all code in 3.7.x (that is still around)
>> into stable and supported code via the 3.8.x branch.
>
> That would be an option and now is probably the time to consider a next
> major release as it's been almost two years since 3.7.0.  We currently
> follow a bi-monthly release cadence and the next release will be
> mid-Sept, so I suggest targeting the next next release (mid-November) at
> nearest.  Let's start planning on the milestone[1].
>
>> I'm happy to help, although it was years since I last did significant
>> work on GnuTLS.
>
> Thank you!

I commented on some of the 3.8.0 issues and created a 3.10.0 milestone
we can move some of the stale 3.8.0 issues if you agree.

>>> If we want to keep 3.6.x, someone would need to invest on updating the
>>> CI infrastructure (either porting the recent changes or switching a
>>> simpler CI configuration for the old branch), which may require
>>> significant effort.
>>
>> The GnuTLS CI takes hours to complete - this seems detrimental to
>> productivity.
>
> We actually know which jobs are taking hours: "make distcheck" and
> cppcheck runs.  Maybe we could turn them off for the stable branch
> (gnutls_3_6_x) for now, using the rules keyword[2].

I think one 'distcheck' test is important (maybe it is possible to speed
up by dropping valgrind or something else that is performed by other
checks anyway), but I ran into the cppcheck too recently that surprised
me.  It is probably of lower importance, and shouldn't hold up a
successful pipeline.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20220902/f1fc79b0/attachment-0001.sig>

From ametzler at bebt.de  Fri Sep  2 18:26:22 2022
From: ametzler at bebt.de (Andreas Metzler)
Date: Fri, 2 Sep 2022 18:26:22 +0200
Subject: [gnutls-help] gnutls 3.7.7
In-Reply-To: <87bkry5ks5.fsf@latte.josefsson.org>
References: <566DD4CF-C7AD-4DA1-9D3D-98513F07BECE@schamschula.com>
 <8735da1dru.fsf-ueno@gnu.org> <87bkry5ks5.fsf@latte.josefsson.org>
Message-ID: <YxIurtaijrbh37Sr@argenau.bebt.de>

On 2022-09-02 Simon Josefsson <simon at josefsson.org> wrote:
> Could you release the 3.7.x branch as 3.8.0 and declare that stable?
> That would effectively turn all code in 3.7.x (that is still around)
> into stable and supported code via the 3.8.x branch.  I'm happy to help,
> although it was years since I last did significant work on GnuTLS.
[...]

Hello,

did the Gnutls version number semantics change?

Iirc for release in 3.x series at some point of time 3.n.m was declared
stable and when 3.n+1 was branched off as next, i.e. there were stable
releases of 3.0, 3.1, ?.

cu Andreas


From simon at josefsson.org  Fri Sep  2 19:56:28 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 02 Sep 2022 19:56:28 +0200
Subject: [gnutls-help] gnutls 3.7.7
In-Reply-To: <YxIurtaijrbh37Sr@argenau.bebt.de> (Andreas Metzler's message of
 "Fri, 2 Sep 2022 18:26:22 +0200")
References: <566DD4CF-C7AD-4DA1-9D3D-98513F07BECE@schamschula.com>
 <8735da1dru.fsf-ueno@gnu.org> <87bkry5ks5.fsf@latte.josefsson.org>
 <YxIurtaijrbh37Sr@argenau.bebt.de>
Message-ID: <87zgfh8xtf.fsf@latte.josefsson.org>

Andreas Metzler <ametzler at bebt.de> writes:

> On 2022-09-02 Simon Josefsson <simon at josefsson.org> wrote:
>> Could you release the 3.7.x branch as 3.8.0 and declare that stable?
>> That would effectively turn all code in 3.7.x (that is still around)
>> into stable and supported code via the 3.8.x branch.  I'm happy to help,
>> although it was years since I last did significant work on GnuTLS.
> [...]
>
> Hello,
>
> did the Gnutls version number semantics change?
>
> Iirc for release in 3.x series at some point of time 3.n.m was declared
> stable and when 3.n+1 was branched off as next, i.e. there were stable
> releases of 3.0, 3.1, ?.

Sorry I don't really know what the semantics are, and incorrectly tried
to document what I thought was the case here:

https://gitlab.com/jas/gnutls/-/commit/e486e2f9a105d37fd73fcd312e9be6025d10221c

Then how about the following as the way forward?  This assumes nobody
has the time to backport security fixes to the 3.6.x branch any more,
and we are confident 3.7.x is stable.

-|stable|3.6.x  |as needed       |
-|next  |3.7.x  |bi-monthly      |
+|stable|3.7.x  |as needed       |
+|next  |3.8.x  |bi-monthly      |

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20220902/f31fa509/attachment.sig>

From ueno at gnu.org  Mon Sep  5 08:03:01 2022
From: ueno at gnu.org (Daiki Ueno)
Date: Mon, 05 Sep 2022 15:03:01 +0900
Subject: [gnutls-help] gnutls 3.7.7
In-Reply-To: <87zgfh8xtf.fsf@latte.josefsson.org> (Simon Josefsson's message
 of "Fri, 02 Sep 2022 19:56:28 +0200")
References: <566DD4CF-C7AD-4DA1-9D3D-98513F07BECE@schamschula.com>
 <8735da1dru.fsf-ueno@gnu.org> <87bkry5ks5.fsf@latte.josefsson.org>
 <YxIurtaijrbh37Sr@argenau.bebt.de>
 <87zgfh8xtf.fsf@latte.josefsson.org>
Message-ID: <87edwqe4tm.fsf-ueno@gnu.org>

Simon Josefsson <simon at josefsson.org> writes:

> Andreas Metzler <ametzler at bebt.de> writes:
>
>> On 2022-09-02 Simon Josefsson <simon at josefsson.org> wrote:
>>> Could you release the 3.7.x branch as 3.8.0 and declare that stable?
>>> That would effectively turn all code in 3.7.x (that is still around)
>>> into stable and supported code via the 3.8.x branch.  I'm happy to help,
>>> although it was years since I last did significant work on GnuTLS.
>> [...]
>>
>> Hello,
>>
>> did the Gnutls version number semantics change?
>>
>> Iirc for release in 3.x series at some point of time 3.n.m was declared
>> stable and when 3.n+1 was branched off as next, i.e. there were stable
>> releases of 3.0, 3.1, ?.

That seems to be the case.  For example, 3.4.0 was released as
stable-next[1] and after a few iterations 3.4.x branch was marked as
stable[2] while 3.5.x was in development in the git master branch.

At some point during the 3.6.x cycle, however, the "next" concept has
been abandoned[1], and afterwards we repurposed it for 3.7.x
development.

> Sorry I don't really know what the semantics are, and incorrectly tried
> to document what I thought was the case here:
>
> https://gitlab.com/jas/gnutls/-/commit/e486e2f9a105d37fd73fcd312e9be6025d10221c

I agree following the semantic versioning scheme is a good idea (we
actually claim as we do[4]).  A drawback is that we can't incorporate
any backward incompatibile change without incrementing the leftmost
non-zero component i.e., "3" in this case.

> Then how about the following as the way forward?  This assumes nobody
> has the time to backport security fixes to the 3.6.x branch any more,
> and we are confident 3.7.x is stable.
>
> -|stable|3.6.x  |as needed       |
> -|next  |3.7.x  |bi-monthly      |
> +|stable|3.7.x  |as needed       |
> +|next  |3.8.x  |bi-monthly      |

Sounds good to me.  I guess all we need is to have a gnutls_3_7_x branch
and proper documentation of the current versioning scheme :-)

Footnotes:
[1]  https://gitlab.com/gnutls/gnutls/-/wikis/face2face-meeting-fosdem2019

[2]  https://lists.gnupg.org/pipermail/gnutls-devel/2015-April/007535.html

[3]  https://lists.gnupg.org/pipermail/gnutls-devel/2015-November/007801.html

[4]  https://bestpractices.coreinfrastructure.org/en/projects/330#changecontrol

Regards,
-- 
Daiki Ueno


From simon at josefsson.org  Tue Sep  6 09:25:12 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 06 Sep 2022 09:25:12 +0200
Subject: [gnutls-help] gnutls 3.7.7
In-Reply-To: <87edwqe4tm.fsf-ueno@gnu.org> (Daiki Ueno's message of "Mon, 05
 Sep 2022 15:03:01 +0900")
References: <566DD4CF-C7AD-4DA1-9D3D-98513F07BECE@schamschula.com>
 <8735da1dru.fsf-ueno@gnu.org> <87bkry5ks5.fsf@latte.josefsson.org>
 <YxIurtaijrbh37Sr@argenau.bebt.de>
 <87zgfh8xtf.fsf@latte.josefsson.org> <87edwqe4tm.fsf-ueno@gnu.org>
Message-ID: <87edwpq813.fsf@latte.josefsson.org>

Daiki Ueno <ueno at gnu.org> writes:

>>> Hello,
>>>
>>> did the Gnutls version number semantics change?
>>>
>>> Iirc for release in 3.x series at some point of time 3.n.m was declared
>>> stable and when 3.n+1 was branched off as next, i.e. there were stable
>>> releases of 3.0, 3.1, ?.
>
> That seems to be the case.  For example, 3.4.0 was released as
> stable-next[1] and after a few iterations 3.4.x branch was marked as
> stable[2] while 3.5.x was in development in the git master branch.
>
> At some point during the 3.6.x cycle, however, the "next" concept has
> been abandoned[1], and afterwards we repurposed it for 3.7.x
> development.

Ah.  So instead of using an odd/even scheme we use a dynamic scheme
where we can change which branch are considered stable vs development by
changing RELEASES.md?  I don't care strongly, as long as the approach is
documented and possible to understand.

>> -|stable|3.6.x  |as needed       |
>> -|next  |3.7.x  |bi-monthly      |
>> +|stable|3.7.x  |as needed       |
>> +|next  |3.8.x  |bi-monthly      |
>
> Sounds good to me.  I guess all we need is to have a gnutls_3_7_x branch
> and proper documentation of the current versioning scheme :-)

So how about this patch?

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Doc-fix-about-version-numbers.patch
Type: text/x-diff
Size: 778 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20220906/50c6a5eb/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20220906/50c6a5eb/attachment.sig>

From ueno at gnu.org  Mon Sep 19 08:39:25 2022
From: ueno at gnu.org (Daiki Ueno)
Date: Mon, 19 Sep 2022 15:39:25 +0900
Subject: [gnutls-help] planning meeting
Message-ID: <877d1zj2aq.fsf-ueno@gnu.org>

Hello,

Simon's post[1] on gnutls-help reminded me that it might be time for a
new branch (i.e., 3.8.x), as it has been already two years since the
3.7.x branching.  I am wondering if we could have a meeting to discuss
plans towards 3.8.0 release as we did for 3.7.0[2], in the first or
second week of October.

If you are willing to attend, let me know your preferred date and time.
I have created a wiki page with initial agenda[3].  Feel free to edit
and add any items.

Footnotes:
[1]  https://lists.gnupg.org/pipermail/gnutls-help/2022-September/004749.html

[2]  https://gitlab.com/gnutls/gnutls/-/wikis/meeting-agenda-2020

[3]  https://gitlab.com/gnutls/gnutls/-/wikis/meeting-agenda-2022

Regards,
-- 
Daiki Ueno


From simon at josefsson.org  Mon Sep 19 11:02:50 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 Sep 2022 11:02:50 +0200
Subject: [gnutls-help] planning meeting
In-Reply-To: <877d1zj2aq.fsf-ueno@gnu.org> (Daiki Ueno's message of "Mon, 19
 Sep 2022 15:39:25 +0900")
References: <877d1zj2aq.fsf-ueno@gnu.org>
Message-ID: <87r10768jp.fsf@latte.josefsson.org>

Hi

I could try to attend, is the approach to meetings documented anywhere?
Irc, chat, video, telephone, etc?  Maybe that could be one agenda item
:)

/Simon

Daiki Ueno <ueno at gnu.org> writes:

> Hello,
>
> Simon's post[1] on gnutls-help reminded me that it might be time for a
> new branch (i.e., 3.8.x), as it has been already two years since the
> 3.7.x branching.  I am wondering if we could have a meeting to discuss
> plans towards 3.8.0 release as we did for 3.7.0[2], in the first or
> second week of October.
>
> If you are willing to attend, let me know your preferred date and time.
> I have created a wiki page with initial agenda[3].  Feel free to edit
> and add any items.
>
> Footnotes:
> [1]  https://lists.gnupg.org/pipermail/gnutls-help/2022-September/004749.html
>
> [2]  https://gitlab.com/gnutls/gnutls/-/wikis/meeting-agenda-2020
>
> [3]  https://gitlab.com/gnutls/gnutls/-/wikis/meeting-agenda-2022
>
> Regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20220919/03554a65/attachment-0001.sig>

From ueno at gnu.org  Mon Sep 19 12:50:01 2022
From: ueno at gnu.org (Daiki Ueno)
Date: Mon, 19 Sep 2022 19:50:01 +0900
Subject: [gnutls-help] planning meeting
In-Reply-To: <87r10768jp.fsf@latte.josefsson.org> (Simon Josefsson's message
 of "Mon, 19 Sep 2022 11:02:50 +0200")
References: <877d1zj2aq.fsf-ueno@gnu.org> <87r10768jp.fsf@latte.josefsson.org>
Message-ID: <8735cniqp2.fsf-ueno@gnu.org>

Simon Josefsson <simon at josefsson.org> writes:

> I could try to attend, is the approach to meetings documented anywhere?
> Irc, chat, video, telephone, etc?  Maybe that could be one agenda item
> :)

Last time we did a video call with Jitsi Meet[1], which might be
convenient this time as well.

Regards,

> /Simon
>
> Daiki Ueno <ueno at gnu.org> writes:
>
>> Hello,
>>
>> Simon's post[2] on gnutls-help reminded me that it might be time for a
>> new branch (i.e., 3.8.x), as it has been already two years since the
>> 3.7.x branching.  I am wondering if we could have a meeting to discuss
>> plans towards 3.8.0 release as we did for 3.7.0[3], in the first or
>> second week of October.
>>
>> If you are willing to attend, let me know your preferred date and time.
>> I have created a wiki page with initial agenda[4].  Feel free to edit
>> and add any items.
>>
>> Footnotes:
>> [2]  https://lists.gnupg.org/pipermail/gnutls-help/2022-September/004749.html
>>
>> [3]  https://gitlab.com/gnutls/gnutls/-/wikis/meeting-agenda-2020
>>
>> [4]  https://gitlab.com/gnutls/gnutls/-/wikis/meeting-agenda-2022
>>
>> Regards,
>
> !DSPAM:6328305012419957806083337!

Footnotes:
[1]  https://meet.jit.si/



From zfridric at redhat.com  Tue Sep 20 13:39:27 2022
From: zfridric at redhat.com (Zoltan Fridrich)
Date: Tue, 20 Sep 2022 13:39:27 +0200
Subject: [gnutls-help] planning meeting
In-Reply-To: <8735cniqp2.fsf-ueno@gnu.org>
References: <877d1zj2aq.fsf-ueno@gnu.org> <87r10768jp.fsf@latte.josefsson.org>
 <8735cniqp2.fsf-ueno@gnu.org>
Message-ID: <CAEtiQY=5ggS0e7SHiY79S1qCRzMbBtKcBxo6bC_AQesSkKQspQ@mail.gmail.com>

Hello,

I will attend the meeting as well. My preferred date and time would be for
instance 4.10. or 27.9. around 9:30 - 12:00 in the morning (Czech, Brno
time).
But any day in the upcoming weeks would do unless it's a holiday or a
weekend.

Regards,
Zoltan

On Mon, Sep 19, 2022 at 12:51 PM Daiki Ueno <ueno at gnu.org> wrote:

> Simon Josefsson <simon at josefsson.org> writes:
>
> > I could try to attend, is the approach to meetings documented anywhere?
> > Irc, chat, video, telephone, etc?  Maybe that could be one agenda item
> > :)
>
> Last time we did a video call with Jitsi Meet[1], which might be
> convenient this time as well.
>
> Regards,
>
> > /Simon
> >
> > Daiki Ueno <ueno at gnu.org> writes:
> >
> >> Hello,
> >>
> >> Simon's post[2] on gnutls-help reminded me that it might be time for a
> >> new branch (i.e., 3.8.x), as it has been already two years since the
> >> 3.7.x branching.  I am wondering if we could have a meeting to discuss
> >> plans towards 3.8.0 release as we did for 3.7.0[3], in the first or
> >> second week of October.
> >>
> >> If you are willing to attend, let me know your preferred date and time.
> >> I have created a wiki page with initial agenda[4].  Feel free to edit
> >> and add any items.
> >>
> >> Footnotes:
> >> [2]
> https://lists.gnupg.org/pipermail/gnutls-help/2022-September/004749.html
> >>
> >> [3]  https://gitlab.com/gnutls/gnutls/-/wikis/meeting-agenda-2020
> >>
> >> [4]  https://gitlab.com/gnutls/gnutls/-/wikis/meeting-agenda-2022
> >>
> >> Regards,
> >
> > !DSPAM:6328305012419957806083337!
>
> Footnotes:
> [1]  https://meet.jit.si/
>
>
> _______________________________________________
> Gnutls-help mailing list
> Gnutls-help at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-help
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20220920/d02edaa6/attachment.html>

From simon at josefsson.org  Tue Sep 20 15:06:06 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 20 Sep 2022 15:06:06 +0200
Subject: [gnutls-help] planning meeting
In-Reply-To: <CAEtiQY=5ggS0e7SHiY79S1qCRzMbBtKcBxo6bC_AQesSkKQspQ@mail.gmail.com>
References: <877d1zj2aq.fsf-ueno@gnu.org>
 <87r10768jp.fsf@latte.josefsson.org> <8735cniqp2.fsf-ueno@gnu.org>
 <CAEtiQY=5ggS0e7SHiY79S1qCRzMbBtKcBxo6bC_AQesSkKQspQ@mail.gmail.com>
Message-ID: <b88abbcb6cde7dcc98f5c6799c64753c08f1686f.camel@josefsson.org>

Both works fine for me too, happy to join you!

/Simon

tis 2022-09-20 klockan 13:39 +0200 skrev Zoltan Fridrich:
> Hello,
> 
> I will attend the meeting as well. My preferred date and time would
> be for
> instance 4.10. or 27.9. around 9:30 - 12:00 in the morning (Czech,
> Brno time).
> But any day in the upcoming weeks would do unless it's a holiday or a
> weekend.
> 
> Regards,
> Zoltan
> 
> On Mon, Sep 19, 2022 at 12:51 PM Daiki Ueno <ueno at gnu.org> wrote:
> > Simon Josefsson <simon at josefsson.org> writes:
> > 
> > > I could try to attend, is the approach to meetings documented
> > anywhere?
> > > Irc, chat, video, telephone, etc?? Maybe that could be one agenda
> > item
> > > :)
> > 
> > Last time we did a video call with Jitsi Meet[1], which might be
> > convenient this time as well.
> > 
> > Regards,
> > 
> > > /Simon
> > > 
> > > Daiki Ueno <ueno at gnu.org> writes:
> > > 
> > > > Hello,
> > > > 
> > > > Simon's post[2] on gnutls-help reminded me that it might be
> > > > time
> > for a
> > > > new branch (i.e., 3.8.x), as it has been already two years
> > > > since
> > the
> > > > 3.7.x branching.? I am wondering if we could have a meeting to
> > discuss
> > > > plans towards 3.8.0 release as we did for 3.7.0[3], in the
> > > > first
> > or
> > > > second week of October.
> > > > 
> > > > If you are willing to attend, let me know your preferred date
> > and time.
> > > > I have created a wiki page with initial agenda[4].? Feel free
> > > > to
> > edit
> > > > and add any items.
> > > > 
> > > > Footnotes:
> > > > [2]?
> > https://lists.gnupg.org/pipermail/gnutls-help/2022-September/004749.html
> > > > 
> > > > [3]?
> > https://gitlab.com/gnutls/gnutls/-/wikis/meeting-agenda-2020
> > > > 
> > > > [4]?
> > https://gitlab.com/gnutls/gnutls/-/wikis/meeting-agenda-2022
> > > > 
> > > > Regards,
> > > 
> > > !DSPAM:6328305012419957806083337!
> > 
> > Footnotes:
> > [1]? https://meet.jit.si/
> > 
> > 
> > _______________________________________________
> > Gnutls-help mailing list
> > Gnutls-help at lists.gnutls.org
> > http://lists.gnupg.org/mailman/listinfo/gnutls-help
> > 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20220920/c636d2de/attachment.sig>

From monk at unboiled.info  Fri Sep 23 13:21:30 2022
From: monk at unboiled.info (Alexander Sosedkin)
Date: Fri, 23 Sep 2022 13:21:30 +0200
Subject: [gnutls-help] planning meeting
In-Reply-To: <CAEtiQY=5ggS0e7SHiY79S1qCRzMbBtKcBxo6bC_AQesSkKQspQ@mail.gmail.com>
References: <877d1zj2aq.fsf-ueno@gnu.org> <87r10768jp.fsf@latte.josefsson.org>
 <8735cniqp2.fsf-ueno@gnu.org>
 <CAEtiQY=5ggS0e7SHiY79S1qCRzMbBtKcBxo6bC_AQesSkKQspQ@mail.gmail.com>
Message-ID: <166393209060.235428.5929784357860569004@localhost>

Quoting zfridric at redhat.com (2022-09-20 13:39:27)
> Hello,
>
> I will attend the meeting as well. My preferred date and time would be for
> instance 4.10. or 27.9. around 9:30 - 12:00 in the morning (Czech, Brno
> time).
> But any day in the upcoming weeks would do unless it's a holiday or a
> weekend.
>
> Regards,
> Zoltan

I'd also like to attend and I'm fine with your suggestions.


From ueno at gnu.org  Tue Sep 27 03:21:08 2022
From: ueno at gnu.org (Daiki Ueno)
Date: Tue, 27 Sep 2022 10:21:08 +0900
Subject: [gnutls-help] planning meeting
In-Reply-To: <166393209060.235428.5929784357860569004@localhost> (Alexander
 Sosedkin's message of "Fri, 23 Sep 2022 13:21:30 +0200")
References: <877d1zj2aq.fsf-ueno@gnu.org> <87r10768jp.fsf@latte.josefsson.org>
 <8735cniqp2.fsf-ueno@gnu.org>
 <CAEtiQY=5ggS0e7SHiY79S1qCRzMbBtKcBxo6bC_AQesSkKQspQ@mail.gmail.com>
 <166393209060.235428.5929784357860569004@localhost>
Message-ID: <87a66lwr23.fsf-ueno@gnu.org>

Alexander Sosedkin <monk at unboiled.info> writes:

> Quoting zfridric at redhat.com (2022-09-20 13:39:27)
>> Hello,
>>
>> I will attend the meeting as well. My preferred date and time would be for
>> instance 4.10. or 27.9. around 9:30 - 12:00 in the morning (Czech, Brno
>> time).
>> But any day in the upcoming weeks would do unless it's a holiday or a
>> weekend.
>>
>> Regards,
>> Zoltan
>
> I'd also like to attend and I'm fine with your suggestions.

OK, let's have the meeting on Oct 4.  As for the time, would the morning
slot, say 10:30 CEST (UTC+2), work for everyone?

We will probably use Jitsi Meet; I'll send you a calendar invite
beforehand and also update the wiki page with the link.

Regards,
-- 
Daiki Ueno


From nicolas at babelouest.org  Tue Sep 27 13:37:10 2022
From: nicolas at babelouest.org (Nicolas Mora)
Date: Tue, 27 Sep 2022 07:37:10 -0400
Subject: [gnutls-help] planning meeting
In-Reply-To: <87a66lwr23.fsf-ueno@gnu.org>
References: <877d1zj2aq.fsf-ueno@gnu.org> <87r10768jp.fsf@latte.josefsson.org>
 <8735cniqp2.fsf-ueno@gnu.org>
 <CAEtiQY=5ggS0e7SHiY79S1qCRzMbBtKcBxo6bC_AQesSkKQspQ@mail.gmail.com>
 <166393209060.235428.5929784357860569004@localhost>
 <87a66lwr23.fsf-ueno@gnu.org>
Message-ID: <2ce961ee-aaaf-eb4d-b1e0-f829ef8fe952@babelouest.org>

Hello,

Le 2022-09-26 ? 21 h 21, Daiki Ueno a ?crit?:
> 
> OK, let's have the meeting on Oct 4.  As for the time, would the morning
> slot, say 10:30 CEST (UTC+2), work for everyone?
> 
> We will probably use Jitsi Meet; I'll send you a calendar invite
> beforehand and also update the wiki page with the link.
> 
I'll try to attend to the meeting if that's ok

/Nicolas


From monk at unboiled.info  Tue Sep 27 09:49:28 2022
From: monk at unboiled.info (Alexander Sosedkin)
Date: Tue, 27 Sep 2022 09:49:28 +0200
Subject: [gnutls-help] planning meeting
In-Reply-To: <87a66lwr23.fsf-ueno@gnu.org>
References: <877d1zj2aq.fsf-ueno@gnu.org> <87r10768jp.fsf@latte.josefsson.org>
 <8735cniqp2.fsf-ueno@gnu.org>
 <CAEtiQY=5ggS0e7SHiY79S1qCRzMbBtKcBxo6bC_AQesSkKQspQ@mail.gmail.com>
 <166393209060.235428.5929784357860569004@localhost>
 <87a66lwr23.fsf-ueno@gnu.org>
Message-ID: <166426496836.588274.4045465835250547238@localhost>

Quoting Daiki Ueno (2022-09-27 03:21:08)
> Alexander Sosedkin <monk at unboiled.info> writes:
>
> > Quoting zfridric at redhat.com (2022-09-20 13:39:27)
> >> Hello,
> >>
> >> I will attend the meeting as well. My preferred date and time would be for
> >> instance 4.10. or 27.9. around 9:30 - 12:00 in the morning (Czech, Brno
> >> time).
> >> But any day in the upcoming weeks would do unless it's a holiday or a
> >> weekend.
> >
> > I'd also like to attend and I'm fine with your suggestions.
>
> OK, let's have the meeting on Oct 4.  As for the time, would the morning
> slot, say 10:30 CEST (UTC+2), work for everyone?
>
> We will probably use Jitsi Meet; I'll send you a calendar invite
> beforehand and also update the wiki page with the link.

Works for me.


From monk at unboiled.info  Tue Sep 27 18:29:55 2022
From: monk at unboiled.info (Alexander Sosedkin)
Date: Tue, 27 Sep 2022 18:29:55 +0200
Subject: [gnutls-help] gnutls 3.7.8
Message-ID: <166429619527.595292.12999133621125778319@localhost>

Hello,

We have just released gnutls-3.7.8.
This is a bug fix and enhancement release on the 3.7.x branch.

We would like to thank everyone who contributed in this release:

Alexander Sosedkin, Andreas Metzler, Daiki Ueno, Doug Nazar,
Franti?ek Kren?elok, Martin Storsj?, Simon Josefsson, Stanislav Zidek,
Tobias Heider and Zolt?n Fridrich.

The detailed list of changes follows:

* Version 3.7.8 (released 2022-09-27)

** libgnutls: In FIPS140 mode, RSA signature verification is an approved
   operation if the key has modulus with known sizes (1024, 1280,
   1536, and 1792 bits), in addition to any modulus sizes larger than
   2048 bits, according to SP800-131A rev2.

** libgnutls: gnutls_session_channel_binding performs additional checks when
   GNUTLS_CB_TLS_EXPORTER is requested. According to RFC9622 4.2, the
   "tls-exporter" channel binding is only usable when the handshake is
   bound to a unique master secret (i.e., either TLS 1.3 or extended
   master secret extension is negotiated). Otherwise the function now
   returns error.

** libgnutls: usage of the following functions, which are designed to
   loosen restrictions imposed by allowlisting mode of configuration,
   has been additionally restricted. Invoking them is now only allowed
   if system-wide TLS priority string has not been initialized yet:
gnutls_digest_set_secure
gnutls_sign_set_secure
gnutls_sign_set_secure_for_certs
gnutls_protocol_set_enabled

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

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

GnuTLS may be downloaded directly from
https://www.gnupg.org/ftp/gcrypt/
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.7/gnutls-3.7.8.tar.xz

Here are OpenPGP detached signatures signed using keys:
E987AB7F7E89667776D05B3BB0E9DD20B29F1432,
5D46CB0F763405A7053556F47A75A648B3F9220C
and
462225C3B46F34879FC8496CD605848ED7E69871:
https://www.gnupg.org/ftp/gcrypt/gnutls/v3.7/gnutls-3.7.8.tar.xz.sig

Note that it has been signed with my OpenPGP key:
pub   rsa4096 2016-09-27 [SC]
      E987AB7F7E89667776D05B3BB0E9DD20B29F1432
uid           [ultimate] Alexander Sosedkin <monk at unboiled.info>
sub   rsa4096 2016-09-27 [E]
sub   rsa4096 2016-09-27 [S]

Zolt?n Fridrich's OpenPGP key:
pub   ed25519 2021-12-23 [SC] [expires: 2023-12-23]
      5D46CB0F763405A7053556F47A75A648B3F9220C
uid           [ultimate] Zoltan Fridrich <zfridric at redhat.com>
sub   cv25519 2021-12-23 [E] [expires: 2023-12-23]

and Daiki Ueno's OpenPGP key:
pub   rsa4096 2009-07-23 [SC] [expires: 2023-09-25]
      462225C3B46F34879FC8496CD605848ED7E69871
uid           [ultimate] Daiki Ueno <ueno at unixuser.org>
uid           [ultimate] Daiki Ueno <ueno at gnu.org>
sub   rsa4096 2010-02-04 [E]

Regards,
Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20220927/cfccb1c9/attachment.sig>

From simon at josefsson.org  Wed Sep 28 14:03:44 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 28 Sep 2022 14:03:44 +0200
Subject: [gnutls-help] planning meeting
In-Reply-To: <87a66lwr23.fsf-ueno@gnu.org> (Daiki Ueno's message of "Tue, 27
 Sep 2022 10:21:08 +0900")
References: <877d1zj2aq.fsf-ueno@gnu.org> <87r10768jp.fsf@latte.josefsson.org>
 <8735cniqp2.fsf-ueno@gnu.org>
 <CAEtiQY=5ggS0e7SHiY79S1qCRzMbBtKcBxo6bC_AQesSkKQspQ@mail.gmail.com>
 <166393209060.235428.5929784357860569004@localhost>
 <87a66lwr23.fsf-ueno@gnu.org>
Message-ID: <87czbfyacf.fsf@latte.josefsson.org>

Daiki Ueno <ueno at gnu.org> writes:

> Alexander Sosedkin <monk at unboiled.info> writes:
>
>> Quoting zfridric at redhat.com (2022-09-20 13:39:27)
>>> Hello,
>>>
>>> I will attend the meeting as well. My preferred date and time would be for
>>> instance 4.10. or 27.9. around 9:30 - 12:00 in the morning (Czech, Brno
>>> time).
>>> But any day in the upcoming weeks would do unless it's a holiday or a
>>> weekend.
>>>
>>> Regards,
>>> Zoltan
>>
>> I'd also like to attend and I'm fine with your suggestions.
>
> OK, let's have the meeting on Oct 4.  As for the time, would the morning
> slot, say 10:30 CEST (UTC+2), work for everyone?
>
> We will probably use Jitsi Meet; I'll send you a calendar invite
> beforehand and also update the wiki page with the link.

Where is the wiki page with the link?

This one?
https://gitlab.com/gnutls/gnutls/-/wikis/meeting-agenda-2022

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20220928/29be15d3/attachment.sig>

From micha-1 at fantasymail.de  Thu Sep 29 12:11:21 2022
From: micha-1 at fantasymail.de (Michael Wohlwend)
Date: Thu, 29 Sep 2022 12:11:21 +0200
Subject: [gnutls-help] help needed with: Alert(21)
Message-ID: <5606626.DvuYhMxLoT@pc21a>

Hi,

I got a problem with a gnutls client-server connection which breaks after 
sending 64GB of data. Most often less data is send, so the problem was not 
recognized. I'm using the gnutls version in debian bullseye. One computer is 
still running debian stretch, where it doesn't break, but just happily handles 
more than 64 GB, so I think the client side is responsible for closing the 
connection.

I have not that much knowing of the gnutls lib and just turned on debug 
output.

The last lines in the log I'm seeing before the connection breaks are:

gnutls[5]: REC[0x564834690fd0]: SSL 3.3 Application Data packet received. 
Epoch 2, length: 27
gnutls[5]: REC[0x564834690fd0]: Expected Packet Application Data(23)
gnutls[5]: REC[0x564834690fd0]: Received Packet Application Data(23) with 
length: 27
gnutls[10]: READ: Got 27 bytes from 0x564834608640
gnutls[10]: READ: read 27 bytes from 0x564834608640
gnutls[10]: RB: Have 5 bytes into buffer. Adding 27 bytes.
gnutls[10]: RB: Requested 32 bytes
gnutls[5]: REC[0x564834690fd0]: Decrypted Packet[0] Application Data(23) with 
length: 10
gnutls[13]: BUF[REC]: Inserted 10 bytes of Data(23)
gnutls[11]: WRITE FLUSH: 0 bytes in buffer.
gnutls[3]: ASSERT: ../../lib/buffers.c[_gnutls_io_write_flush]:696
gnutls[5]: REC: Sending Alert[1|0] - Benachrichtigung schlie?en (notify close)
gnutls[5]: REC[0x564834690fd0]: Preparing Packet Alert(21) with length: 2 and 
min pad: 0
gnutls[9]: ENC[0x564834690fd0]: cipher: AES-256-GCM, MAC: AEAD, Epoch: 2
gnutls[11]: WRITE: enqueued 24 bytes for 0x564834608640. Total 24 bytes.
gnutls[11]: WRITE FLUSH: 24 bytes in buffer.
gnutls[11]: WRITE: wrote 24 bytes, 0 bytes left.
gnutls[5]: REC[0x564834690fd0]: Sent Packet[2] Alert(21) in epoch 2 and 
length: 24
gnutls[10]: READ: Got 0 bytes from 0x564834608640
gnutls[10]: READ: read 0 bytes from 0x564834608640
gnutls[3]: ASSERT: ../../lib/buffers.c[_gnutls_io_read_buffered]:593
gnutls[3]: ASSERT: ../../lib/record.c[recv_headers]:1184
gnutls[3]: ASSERT: ../../lib/record.c[_gnutls_recv_in_buffers]:1310
gnutls[3]: ASSERT: ../../lib/record.c[_gnutls_recv_in_buffers]:1614
gnutls[13]: BUF[HSK]: Emptied buffer
gnutls[5]: REC[0x564834690fd0]: Start of epoch cleanup
gnutls[5]: REC[0x564834690fd0]: End of epoch cleanup
gnutls[5]: REC[0x564834690fd0]: Epoch #2 freed


Doesn't Alert(21) means "Decryption failed" ?  but why, when it works before?

Has something changed between versions 3.5 and 3.7 which explains that 64G 
border?

Thanks for helping,
 Michael







From ueno at gnu.org  Thu Sep 29 15:49:25 2022
From: ueno at gnu.org (Daiki Ueno)
Date: Thu, 29 Sep 2022 22:49:25 +0900
Subject: [gnutls-help] planning meeting
In-Reply-To: <87czbfyacf.fsf@latte.josefsson.org> (Simon Josefsson's message
 of "Wed, 28 Sep 2022 14:03:44 +0200")
References: <877d1zj2aq.fsf-ueno@gnu.org> <87r10768jp.fsf@latte.josefsson.org>
 <8735cniqp2.fsf-ueno@gnu.org>
 <CAEtiQY=5ggS0e7SHiY79S1qCRzMbBtKcBxo6bC_AQesSkKQspQ@mail.gmail.com>
 <166393209060.235428.5929784357860569004@localhost>
 <87a66lwr23.fsf-ueno@gnu.org> <87czbfyacf.fsf@latte.josefsson.org>
Message-ID: <8735cai93u.fsf-ueno@gnu.org>

Hello,

Simon Josefsson <simon at josefsson.org> writes:

> Daiki Ueno <ueno at gnu.org> writes:
>
>> Alexander Sosedkin <monk at unboiled.info> writes:
>>
>>> Quoting zfridric at redhat.com (2022-09-20 13:39:27)
>>>> Hello,
>>>>
>>>> I will attend the meeting as well. My preferred date and time would be for
>>>> instance 4.10. or 27.9. around 9:30 - 12:00 in the morning (Czech, Brno
>>>> time).
>>>> But any day in the upcoming weeks would do unless it's a holiday or a
>>>> weekend.
>>>>
>>>> Regards,
>>>> Zoltan
>>>
>>> I'd also like to attend and I'm fine with your suggestions.
>>
>> OK, let's have the meeting on Oct 4.  As for the time, would the morning
>> slot, say 10:30 CEST (UTC+2), work for everyone?
>>
>> We will probably use Jitsi Meet; I'll send you a calendar invite
>> beforehand and also update the wiki page with the link.
>
> Where is the wiki page with the link?
>
> This one?
> https://gitlab.com/gnutls/gnutls/-/wikis/meeting-agenda-2022

Yes.  I have updated the wiki with the joining information.  Currently
it links to the meeting URL for guests; I will send the moderator URL
for those expressed interest in attending, in another email.

Regards,
-- 
Daiki Ueno


From ueno at gnu.org  Fri Sep 30 10:32:32 2022
From: ueno at gnu.org (Daiki Ueno)
Date: Fri, 30 Sep 2022 17:32:32 +0900
Subject: [gnutls-help] help needed with: Alert(21)
In-Reply-To: <5606626.DvuYhMxLoT@pc21a> (Michael Wohlwend's message of "Thu,
 29 Sep 2022 12:11:21 +0200")
References: <5606626.DvuYhMxLoT@pc21a>
Message-ID: <87o7ux1cv3.fsf-ueno@gnu.org>

Hello Michael,

Michael Wohlwend <micha-1 at fantasymail.de> writes:

> I got a problem with a gnutls client-server connection which breaks after 
> sending 64GB of data. Most often less data is send, so the problem was not 
> recognized. I'm using the gnutls version in debian bullseye. One computer is 
> still running debian stretch, where it doesn't break, but just happily handles 
> more than 64 GB, so I think the client side is responsible for closing the 
> connection.

I need a bit more information to answer properly:

Are both client and server programs using GnuTLS?  If yes, could you
provide the exact package versions, for both client and server?

> I have not that much knowing of the gnutls lib and just turned on debug 
> output.
>
> The last lines in the log I'm seeing before the connection breaks are:
>
[...]
> gnutls[5]: REC: Sending Alert[1|0] - Benachrichtigung schlie?en (notify close)
> gnutls[5]: REC[0x564834690fd0]: Preparing Packet Alert(21) with length: 2 and 
> min pad: 0
> gnutls[9]: ENC[0x564834690fd0]: cipher: AES-256-GCM, MAC: AEAD, Epoch: 2
[...]
> Has something changed between versions 3.5 and 3.7 which explains that 64G 
> border?

64 GB is above the limit of AES-GCM being safely used without rekeying.
If TLS 1.3 is negotiated GnuTLS initiates automatic rekeying, though TLS
1.3 is a feature supported by GnuTLS 3.6 or later.

Perhaps you could try other ciphers that doesn't have such limitation,
e.g., CHACHA20-POLY1305?

Regards,
-- 
Daiki Ueno


From micha-1 at fantasymail.de  Fri Sep 30 14:05:04 2022
From: micha-1 at fantasymail.de (Michael Wohlwend)
Date: Fri, 30 Sep 2022 14:05:04 +0200
Subject: [gnutls-help] help needed with: Alert(21)
In-Reply-To: <87o7ux1cv3.fsf-ueno@gnu.org>
References: <5606626.DvuYhMxLoT@pc21a> <87o7ux1cv3.fsf-ueno@gnu.org>
Message-ID: <2847796.e9J7NaK4W3@pc21a>

Hi,

thanks for the answers...

Am Freitag, 30. September 2022, 10:32:32 CEST schrieb Daiki Ueno:
> I need a bit more information to answer properly:

> Are both client and server programs using GnuTLS?  If yes, could you
> provide the exact package versions, for both client and server?

client and server are both 3.7.1
It also  works with the 3.5.8 client from debian stretch

If I limit the protocol to tls1.2 it also works.
>
> 64 GB is above the limit of AES-GCM being safely used without rekeying.

ah, yes, , AES-256-GCM, MAC AEAD is  used, so this seems to be the reason.

> If TLS 1.3 is negotiated GnuTLS initiates automatic rekeying, though TLS
> 1.3 is a feature supported by GnuTLS 3.6 or later.


hm, but this rekeying doesn't seem to happen. Otherwise it would work.
Does gnutls_record_recv  gets the GNUTLS_E_REHANDSHAKE as return value in this
case?


> Perhaps you could try other ciphers that doesn't have such limitation,
> e.g., CHACHA20-POLY1305?
> Regards,
>
I will try this

Cheers
 Michael







From micha-1 at fantasymail.de  Fri Sep 30 16:58:07 2022
From: micha-1 at fantasymail.de (Michael Wohlwend)
Date: Fri, 30 Sep 2022 16:58:07 +0200
Subject: [gnutls-help] help needed with: Alert(21)
In-Reply-To: <87o7ux1cv3.fsf-ueno@gnu.org>
References: <5606626.DvuYhMxLoT@pc21a> <87o7ux1cv3.fsf-ueno@gnu.org>
Message-ID: <7433456.EvYhyI6sBW@pc21a>

a little update...

Am Freitag, 30. September 2022, 10:32:32 CEST schrieb Daiki Ueno:
> Hello Michael,
> Perhaps you could try other ciphers that doesn't have such limitation,
> e.g., CHACHA20-POLY1305?
>

I wrote the following in the config:

[overrides]
tls-disabled-cipher= aes-256-gcm


This makes gnutls use chacha20-poly1305 and with this cipher it works.

So what should I do in my code to make this work with aes?  What api calls are
necessary to handle the rekeying correctly?

Cheers + thanks,
 Michael