<!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/asosedkin">Alexander Sosedkin</a>
<a href="https://gitlab.com/gnutls/gnutls/-/issues/1172#note_530521992">commented</a>:
</p>
<div style="">
<p dir="auto">So, the effective configuration now, with a config specifying "hard-disabled" and "config-priority" is:</p>
<ul dir="auto">
<li>for non-TLS: "everything - hard-disabled",</li>
<li>for TLS not using <code>@SYSTEM</code>: "<em>priority</em>",</li>
<li>for TLS using <code>@SYSTEM:extra-priority</code>: "config-priority +- <em>extra-priority</em> - hard-disabled".</li>
</ul>
<p dir="auto">And what we're aiming for given a config that specifies "soft-disabled", "hard-disabled" and "config-priority":</p>
<ul dir="auto">
<li>for non-TLS: "everything - soft-disabled +- <em>new-api</em> - hard-disabled",</li>
<li>for TLS not using @system: "<em>priority</em> +- <em>new-api</em>",</li>
<li>for TLS using @system:extra-priority: "config-priority - soft-disabled +- <em>extra-priority</em> +- <em>new-api</em> - hard-disabled".</li>
</ul>
<p dir="auto">(italics signify what's under the application control)</p>
<p dir="auto">Questions:</p>
<ul dir="auto">
<li>did I get your proposal right?</li>
<li>do we want new API to affect TLS or not? why?</li>
<li>will we have everything soft-disabled reenableable with either priority strings or new-api?</li>
<li>will we have priority-string-format keywords for everything, so that a TLS app could forego new-api and only use priority string?</li>
<li>if we will have priority-string keywords for everything, can we simplify it somehow? The "priority - soft-disabled +- <em>extra-priority</em> +- <em>new-api</em> - hard-disabled" might be not that hard to merge, but sounds hard to comprehend.</li>
<li>how orthogonal are new-api and adding soft-disablement?</li>
</ul>
<p dir="auto">And now for something completely different: maybe my original request is misguided. Now I'm not sure why vendors go the disabling way at all (<a href="https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/issues/22" data-original="https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/issues/22" data-link="false" data-link-reference="true" data-project="2738229" data-issue="50083860" data-reference-type="issue" data-container="body" data-placement="top" title="gnutls policies build upon gnutls NORMAL and not NONE" class="gfm gfm-issue has-tooltip">redhat-crypto/fedora-crypto-policies#22</a>). Maybe we should do soft-enabling instead, for writing future-proof config files that don't change effective configuration on gnutls adding new algorithms? Or allow both with smth like <code>default=everything / default=nothing</code>?</p>
<p dir="auto">This is hard =)</p>
</div>
</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #666;">
—
<br>
Reply to this email directly or <a href="https://gitlab.com/gnutls/gnutls/-/issues/1172#note_530521992">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/ca7e7167d11ec3679c877f64f21d452c/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/1172#note_530521992"}}</script>
</p>
</div>
</body>
</html>