<!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>In terms of "default" built-ins, I'd love to be able to provide at configure time "disabled-versions" list. And for example, allow people to "reset" it by using "disabled-versions =" which would explicitly reset the list of disabled-versions back to none. This is similar to the ini-syntax that systemd units use to reset/override otherwise additive keys with system drop-ins.</p>

</blockquote>

<p dir="auto">But that would seem to me very restricted, as it focuses only in one aspect of settings (tls versions). The rest of the settings (algorithms, hashes, etc.) will not be covered, and that will lead to a piecemeal approach and feels to me that the handling of that disablement will become very complex if not unmanageable. For example with the patch you propose I see how I can disable TLS1.0 and TLS1.1 on configure time, but how do I do the same for SHA256? Even a version like TLS1.2 cannot be handled by the configure logic.</p>

<blockquote dir="auto">

<p>I don't think enforcing the presence of the configuration file is sensible. Especially since until now, no config was provided or necessary.</p>

</blockquote>

<p dir="auto">True, I was not thinking about a universal requirement, but one that is asked during configure time. So distributions which require a config can do so.</p>

<blockquote dir="auto">

<p>Or maybe I should just stop compiling in TLSv1.1 and lower, and just be done with it.</p>

</blockquote>

<p dir="auto">True. That may be a way out. I am not sure how far we can get for it. I know we could not convince the fedora community to move from TLS1.0 and TLS1.1. As long as browsers enable them, it would be very hard to differ from a library like gnutls.</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_270532318">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/bbd93b886444bc227622e73224c1c5c3/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_270532318"}}</script>

</p>

</div>

</body>

</html>