<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html lang="en">
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<title>
GitLab
</title>
<style>img {
max-width: 100%; height: auto;
}
</style>
</head>
<body>
<div class="content">
<div>
<blockquote dir="auto">
<blockquote>
<p><a href="https://gitlab.com/ametzler" data-user="301779" data-reference-type="user" data-container="body" data-placement="bottom" class="gfm gfm-project_member has-tooltip" title="Andreas Metzler">@ametzler</a> 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?</p>
</blockquote>
<p>to be honest I do not think there is a lot <em>I</em> could contribute there.
(Coding skills)</p>
</blockquote>
<p dir="auto">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.</p>
<blockquote dir="auto">
<p>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 <em>one</em>
set of releases. (Unless there is an ABI break).</p>
</blockquote>
<p dir="auto">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:</p>
<ul dir="auto">
<li>Changes which improve the longevity of the release such as:</li>
</ul>
<ul dir="auto">
<li>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).</li>
<li>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)</li>
</ul>
<ul dir="auto">
<li>Important functionality problems in the existing code base (e.g., infinite loop when pin-value was used,
fixes on <code>gnutls_certificate_set_*key()</code> relating to freeing of mem, ALPN fixes).</li>
<li>New functionality</li>
</ul>
<ul dir="auto">
<li>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)</li>
<li>To enable some important software to run with the older version (e.g, the addition of <code>gnutls_x509_crt_set_issuer_unique_id</code> was driven by samba's needs)</li>
</ul>
<p dir="auto">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?</p>
<blockquote dir="auto">
<blockquote>
<p>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.</p>
</blockquote>
</blockquote>
<p dir="auto">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?</p>
</div>
</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #777777;">
—
<br>
Reply to this email directly or <a href="https://gitlab.com/gnutls/gnutls/issues/588#note_110623596">view it on GitLab</a>.
<br>
You're receiving this email because of your account on gitlab.com.
If you'd like to receive fewer emails, you can
<a href="https://gitlab.com/sent_notifications/908da9686ace52d7bb705b98a742e7a0/unsubscribe">unsubscribe</a>
from this thread or
adjust your notification settings.
<script type="application/ld+json">{"@context":"http://schema.org","@type":"EmailMessage","action":{"@type":"ViewAction","name":"View Issue","url":"https://gitlab.com/gnutls/gnutls/issues/588#note_110623596"}}</script>
</p>
</div>
</body>
</html>