[gnutls-help] 3.6.7 interoperability problems with earlier 3.6.x

Andreas Metzler ametzler at bebt.de
Sun Jun 9 11:38:42 CEST 2019


On 2019-06-09 Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:
> On Sat, 2019-06-08 at 11:29 +0200, Andreas Metzler wrote:
[...] 
> > I am now wondering on what to do with this bug for the next Debian
> > stable release ("buster").
> > * We are unlikely to upgrade to 3.6.8 since buster is already frozen.

> What is blocking the upgrade to 3.6.8? Is there some further change to
> do in the development rules so that debian can follow the stable
> branch?

Hello Nikos,

the rules [1] for updates for the soon-to-be-released "buster" are very
tight, every update is reviewed indiviually by an actual person.
---------------
* targeted fixes for release critical bugs (i.e., bugs of severity
  critical, grave, and serious) in all packages;
* fixes for severity: important bugs in packages of priority: optional,
  only when this can be done via unstable;
* translation updates and documentation fixes that are included with
  fixes for the above criteria;
[...]
A targeted fix is one with only the minimum necessary changes to resolve
a bug.
---------------

(An important bug is defined as "a bug which has a major effect on the
usability of a package, without rendering it completely unusable to
everyone.")

A GnuTLS release on the stable branch OTOH can contain a lot more than
that (essentially everything that does not break the API.). Looking at
commits in 3.6.8 we find a lot of stuff that would not do for a Debian
stable/frozen update.
* beautification 8e28bb311ab33a1e7886e46af167311534070c39
* New features (e.g AES-XTS)
* cleanup (344c77b755f68370a098b90ef2ce981b829dd534 handshake: remove
  unnecessary HSK_CRT_SENT flag)
* Improvements for the test-suite  

I do not think that this is really solvable. GnuTLS and Debian release
time are just not aligned and are not alignable. It is a matter of
scale. - Debian cannot start doing bi-monthly stable releases including
feature upgrades and GnuTLS would not improve if it switched to
bi-annual releases (all new features happening in the unstable branch
which was almost untested).

> Having multiple gnutls versions in the major distributions with
> diverse behaviors would make things not easy in terms of
> interoperability for tls1.3 or any other future feature.

I think that is unavoidable.

If you can think of specific changes in 3.6.8 that you think I should
cherry-pick I would be very grateful. Perhaps #720 (IDNA)?

TIA, cu Andreas

[1] https://release.debian.org/buster/freeze_policy.html
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



More information about the Gnutls-help mailing list