<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html lang="en" style='--code-editor-font: var(--default-mono-font, "GitLab Mono"), JetBrains Mono, Menlo, DejaVu Sans Mono, Liberation Mono, Consolas, Ubuntu Mono, Courier New, andale mono, lucida console, monospace;'>
<head>
<meta content="text/html; charset=US-ASCII" http-equiv="Content-Type">
<title>
GitLab
</title>
<style data-premailer="ignore" type="text/css">
a { color: #1068bf; }
</style>
<style>img {
max-width: 100%; height: auto;
}
body {
font-size: .875rem;
}
body {
-webkit-text-shadow: rgba(255,255,255,.01) 0 0 1px;
}
body {
font-family: "GitLab Sans",-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,"Noto Sans",Ubuntu,Cantarell,"Helvetica Neue",sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji"; font-size: inherit;
}
</style>
</head>
<body style='font-size: inherit; -webkit-text-shadow: rgba(255,255,255,.01) 0 0 1px; font-family: "GitLab Sans",-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,"Noto Sans",Ubuntu,Cantarell,"Helvetica Neue",sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji";'>
<div class="content">
<p class="details" style="font-style: italic; color: #737278;">
<a href="https://gitlab.com/asosedkin">Alexander Sosedkin</a> created an issue: <a href="https://gitlab.com/gnutls/gnutls/-/issues/1564">#1564</a>
</p>
<div class="md" style="color: #28272d; word-wrap: break-word;">
<p dir="auto" style="color: #28272d; margin: 0 0 16px;" align="initial"><a href="https://gitlab.com/gnutls/gnutls/-/merge_requests/1550" data-reference-type="merge_request" data-original="!1550" data-link="false" data-link-reference="false" data-merge-request="144369512" data-project="179611" data-project-path="gnutls/gnutls" data-iid="1550" data-container="body" data-placement="top" title="Make gnutls compliant to RFC5280" class="gfm gfm-merge_request" style="margin-top: 0;">!1550 (merged)</a> has introduced, and <a href="https://gitlab.com/gnutls/gnutls/-/merge_requests/1583" data-reference-type="merge_request" data-original="!1583" data-link="false" data-link-reference="false" data-merge-request="153215139" data-project="179611" data-project-path="gnutls/gnutls" data-iid="1583" data-container="body" data-placement="top" title="Improve certificate sanity checks" class="gfm gfm-merge_request">!1583 (merged)</a> has extended <code style='font-size: 90%; color: #18171d; word-wrap: break-word; background-color: #ececef; border-radius: .25rem; font-weight: inherit; font-family: "GitLab Mono","JetBrains Mono","Menlo","DejaVu Sans Mono","Liberation Mono","Consolas","Ubuntu Mono","Courier New","andale mono","lucida console",monospace; vertical-align: bottom; white-space: pre-wrap; overflow-wrap: break-word; word-break: keep-all; padding: 2px 4px;'>--strict-x509</code>, but, without being enabled by default, the compliance improvements offered by the switch lie dormant.
On the other hand, enabling the option comes at an interoperability cost, so packagers are discouraged to enabled it, as when users encounter a non-compliant certificate and come to them, their workarounding options are currently limited to recompiling gnutls only. Introducing some form of a runtime switch might help them make the leap.</p>
<p dir="auto" style="color: #28272d; margin: 0 0 16px;" align="initial">A runtime switch can come in several varieties. In the most common scenario, where a client cannot connect to a server and has no control over the non-compliant certificate it's using, the ideal override would be per-host, and the second best override would be per-invocation, followed by whole-system. Per-app switching, when a specific app wants an override through the API, feels like the least likely to be handy. With that in mind, here's my subjective rating of what the switch could be:</p>
<ol dir="auto" style="text-align: initial; margin: 0 0 16px; padding: 0;">
<li style="margin-top: 0; line-height: 1.6em; margin-left: 25px; padding-left: 3px;">environment variable. Pros: per-invocation. Cons: SUID binaries might ignore it. (not sure how significant is that)</li>
<li style="line-height: 1.6em; margin-left: 25px; padding-left: 3px;">priority string keyword. Pros: some apps allow configuring it per-invocation or per-app. Cons: not easy to enable system-wide with allowlisting config alone (not sure how significant is that)</li>
<li style="line-height: 1.6em; margin-left: 25px; padding-left: 3px;">configuration file directive. Pros: can be per-invocation if pointed at a config with an envvar. Cons: folks rocking no config (e.g. Debian) will have to figure out creating one</li>
</ol>
<p dir="auto" style="color: #28272d; margin: 0 0 16px;" align="initial">Another question is, when can the default for the compile switch be flipped. Next second version bump after a runtime switch is there?</p>
<p dir="auto" style="color: #28272d; margin: 0;" align="initial">Overall, what's the plan to proceed with this one?</p>
</div>
</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #737278;">
—
<br>
Reply to this email directly or <a href="https://gitlab.com/gnutls/gnutls/-/issues/1564">view it on GitLab</a>.
<br>
You're receiving this email because of your account on <a target="_blank" rel="noopener noreferrer" href="https://gitlab.com">gitlab.com</a>. <a href="https://gitlab.com/-/sent_notifications/b4a300f089d7fffe5b5e5b4e8cf3cf5c/unsubscribe" target="_blank" rel="noopener noreferrer">Unsubscribe</a> from this thread · <a href="https://gitlab.com/-/profile/notifications" target="_blank" rel="noopener noreferrer" class="mng-notif-link">Manage all notifications</a> · <a href="https://gitlab.com/help" target="_blank" rel="noopener noreferrer" class="help-link">Help</a>
<script type="application/ld+json">{"@context":"http://schema.org","@type":"EmailMessage","action":{"@type":"ViewAction","name":"View Issue","url":"https://gitlab.com/gnutls/gnutls/-/issues/1564"}}</script>
</p>
</div>
</body>
</html>