[gnutls-help] gnutls 3.7.7

[Simon Josefsson]

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>