[gnutls-devel] GnuTLS | Clarify or improve our supported releases meaning (#588)

[Development of GNU's TLS library]

>> @ametzler any thoughts on that? The situation we have now is that at
>> any ABI breakage the previous release (e.g., 2.12.x, 3.3.x) became a
>> de-facto LTS release as distributions like debian/rhel rely on it
>> cannot move forward. So first question is, would you as debian
>> maintainer be interested in a collaborative maintainership of a
>> similar LTS branch in the future? Ie. bring the debian patches if any
>> and thus also have a say on what other patches go in and on how long
>> would that be open? (and such offer would be open to other
>> distributions) Would that make sense from your perspective?
> 
> to be honest I do not think there is a lot _I_ could contribute there.
> (Coding skills)

I do not think that could be a problem; although backporting of the features is necessary, the main aspect of such releases is agreeing on the policy to follow for it, and enforcing it.

> Also we are quite limited in what changes are acceptable for Debian
> stable - just fixing security issue and important bugs. This simply does
> not match with how GnuTLS stable releases work, they include fixes for
> minor issues, too. Up until 3.6 cherry-picked new features from the
> development branch were also included, but with the new symbol-versioning
> policy [1] afaiui this has changed, new features only can appear in _one_
> set of releases. (Unless there is an ABI break).

Yes, the rules were pretty lax in the past, but were getting finer as I was getting more accustomed with the needs of an OS. What are the current drivers for the stable 3.3.x branches are apart from  security issues:
 * Changes which improve the longevity of the release such as:
  - Fixing compatibility problems caused by that release (i.e., not harming a moving ecosystem) - that was also one of the reasons for the last 2.12.24 release. That includes certificate validation issues (e.g., false negatives).
  - Hardening when possible to (e.g., the enforcing of DER rules in 3.3.x branch, raising crypto bar by removing HMAC-SHA384 and SHA256 in 3.5.x)
 * Important functionality problems in the existing code base (e.g., infinite loop when pin-value was used, 
fixes on `gnutls_certificate_set_*key()` relating to freeing of mem, ALPN fixes).
 * New functionality
  - To load or generate files in common use (e.g., PKCS#8 enhancements), or support some hardware in common use (via PKCS#11 or TPM)
  - To enable some important software to run with the older version (e.g, the addition of `gnutls_x509_crt_set_issuer_unique_id` was driven by samba's needs)

So I'm not sure which would fall under the important definition for Debian, but we could certainly agree on a common ground so that a future LTS release is not only more widely useful but also followed more widely. What do you think?

>> The second (related) question is that if we keep ABI fixed to the one
>> in 3.4.x, would it make sense to create a similar LTS release in the
>> future after 3.3.x is considered out of support?
> For Debian we currently have 3.5.8 in stable and 3.3.8 in oldstable, due
> to the timing of the respective releases we have not shipped 3.4.x in
> a release.

Does this mean that de facto 3.5.8.x became an LTS release in debian? Would declaring 3.6.x or some other future version and LTS release, help to select which version to ship on the next stable and follow it (assuming there is an agreed common set of rules), or would you always prefer to be on the latest branch? For example if we had declared 3.3.x an LTS, would the previous stable had stayed with it, or would it had shipped the 3.5 branch?

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/588#note_110623596
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20181022/c15598d1/attachment.html>