<div dir="ltr">Hi Nikos,<div><br></div><div>OK, I'll move it there about tomorrow – I was not sure which place is ideal (it's quite different in different libraries).</div><div><br></div><div>Thanks for the tip,</div><div>Martin.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 6 Mar 2020 at 16:08, Nikos Mavrogiannopoulos <<a href="mailto:nmav@gnutls.org">nmav@gnutls.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Martin,<br>
 Would you like to move your questions to our <a href="http://gitlab.com" rel="noreferrer" target="_blank">gitlab.com</a> site as an<br>
issue to initiate the discussion? I am not sure all in the development<br>
team follow this mailing list.<br>
<br>
regards,<br>
Nikos<br>
<br>
On Thu, Mar 5, 2020 at 4:48 PM Martin Ukrop <<a href="mailto:mukrop@mail.muni.cz" target="_blank">mukrop@mail.muni.cz</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> I’m the lead of a university project investigating (and improving) the usability of certificate validation errors. Our goal is to simplify the ecosystem by consolidating the errors and their documentation in one place, providing replicable example certificates for all validation errors and by explaining better what the individual errors mean. The project is live at <a href="https://x509errors.org/" rel="noreferrer" target="_blank">https://x509errors.org/</a><br>
><br>
> Now we are reaching out to library developers and users (you) to ask for feedback.<br>
><br>
> Currently, we base the system on OpenSSL errors (as it’s the most common). We have example certificates for 30+ OpenSSL errors and in-progress mapping for corresponding errors error for OpenSSL, GnuTLS, Botan and MbedTLS.<br>
> In the future, we plan the possibility of web reorganization based on the other libraries (currently, the web is organized by OpenSSL), adding the error frequencies based on IP-wide scans and elaborating on the consequences of individual errors.<br>
> Ultimately, we want to propose better (ideally user-tested) errors and their documentation. (Just recently, we made a survey among 180 developers regarding their error documentation preference with good reception).<br>
><br>
> As developers/users of TLS libraries, what do you think of the idea?<br>
> * Which part(s) do you find the most/least useful?<br>
> * Is there anything you see missing?<br>
> * What are your thoughts on unifying the error taxonomy? (a very long-term goal, if at all possible)<br>
><br>
> During spring, we would like to start creating pull requests improving the documentation and error messages in some of the libraries. Would you welcome such contributions?<br>
><br>
> For transparency: My PhD is done at Masaryk University (Czech Republic) and I’m partially supported by Red Hat Czech.<br>
><br>
> With regards,<br>
> Martin.<br>
> _______________________________________________<br>
> Gnutls-help mailing list<br>
> <a href="mailto:Gnutls-help@lists.gnutls.org" target="_blank">Gnutls-help@lists.gnutls.org</a><br>
> <a href="http://lists.gnupg.org/mailman/listinfo/gnutls-help" rel="noreferrer" target="_blank">http://lists.gnupg.org/mailman/listinfo/gnutls-help</a><br>
</blockquote></div>