<!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=US-ASCII" http-equiv="Content-Type">
<title>
GitLab
</title>
<style>img {
max-width: 100%; height: auto;
}
</style>
</head>
<body>
<div class="content">
<p style="color: #777777;">
<a href="https://gitlab.com/nmav">Nikos Mavrogiannopoulos</a>
commented:
</p>
<div style="">
<blockquote dir="auto">
<p>Yes the proposed implementation in this PR currently buggy, I will fix it up. The intention was for disabled-version to trump supported-version.</p>
</blockquote>
<blockquote dir="auto">
<p>"expectations in terms of minimum security" is never a one-way street. What may be universally viewed as secure/insecure, may not be viewed as such by someone else. For example, using "disabled-versions = tls1.3" is usually done out of distrust or lack of current compliance, rather than because tls1.3 is broken. Or disabling/enabling ECC/GOST/etc.</p>
</blockquote>
<p dir="auto">True. This is also the reason I think changing the approach is a slippery slope. The approach you are suggesting is not limited to protocol versions only, it will need to extend to hash algorithms (sha1, etc) as they become deprecated, or key exchange algorithms. That cannot be done with this patch set. The minimum bar configuration will still be there, however there will be some different config option for the protocols.</p>
<blockquote dir="auto">
<p>Plus I want to introduce a distinction, between what is not compiled in (ie. the removed GPG support), and what is compiled in (TLS1.3) and what is compiled-in yet not enabled by default (i.e. TLS1.0 or GOST, or FIPS, or invest NOT-GOST). So yes, this is a soft-disable, to make it just enough annoying for people to move off TLS1.0. I cannot just drop TLS1.0 just yet, without allowing users to access it unfortunately, but I must start sunsetting it. TLSv1.2 is at 96.5% support in the SSl Pulse. Meaning 3.5% public sites (+ lots private ones) will be inaccessible if I just drop TLS1.0, thus an escape hatch is needed. Eventually I would want to stop compiling TLS1.0/1.1 support at all, but I envision that might only be viable in 2-4 years time.</p>
</blockquote>
<blockquote dir="auto">
<p>In Debian and Ubuntu, we currently do not ship a gnutls configuration file. Introducing a configuration file is cumbersome (this is to say users will be grumpy, given that previously it was not required). It can be bypassed with an environment variable. And one has to ensure that the configuration file is copied around into chroots/containers/initrd/snap along with the library. And any LSM confinements (apparmor,selinux,smack,etc) need to be adjusted to permit access to it. Overall, I wouldn't want to rely on neglecting to copy a config file around to enforce a particular distributor minimum requirements.</p>
</blockquote>
<p dir="auto"><code>chroot()</code> environments do not have an issue with the configuration because it is loaded at process load, before chroot. Containers the same as they are build from packages and you have direct control on the dependencies. You've got a point though with the fact that a specific confinement can restrict control of the configuration file and we have no way to enforce its reading.</p>
<blockquote dir="auto">
<p>To contrast, Fedora, for example, compiles gnutls with default priority string set to "@system" meaning that the library has never worked, unless a config file that defines SYSTEM is available <em>or</em> the app specifies their own priority string.</p>
</blockquote>
<p dir="auto">There are few options that I see here.</p>
<ul dir="auto">
<li>One that you suggest is change the logic and have the built-in be the "default" level that a distribution may want. That would require though a re-framing of the config as it is now, to make it possible to raise/lower the default bar according to what is desired, in all algorithm sets.</li>
<li>The other is simpler, and is to add an option to error when the default configuration file is not present. That way a distributor can be assured that its configuration is used or the application fails.</li>
</ul>
<p dir="auto"><a href="https://gitlab.com/lumag" data-user="112173" data-reference-type="user" data-container="body" data-placement="bottom" class="gfm gfm-project_member" title="Dmitry Eremin-Solenikov">@lumag</a> <a href="https://gitlab.com/xnox" data-user="107955" data-reference-type="user" data-container="body" data-placement="bottom" class="gfm gfm-project_member" title="Dimitri John Ledkov">@xnox</a> What do you think?</p>
</div>
</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #777;">
—
<br>
Reply to this email directly or <a href="https://gitlab.com/gnutls/gnutls/merge_requests/1157#note_268598770">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/aaa963d97a19f9ff88fcf0c43bdeee57/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 Merge request","url":"https://gitlab.com/gnutls/gnutls/merge_requests/1157#note_268598770"}}</script>
</p>
</div>
</body>
</html>