[Bug 29018] Allow interactive TLS certificate verification

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29018

--- Comment #10 from Cosimo Cecchi <cosimoc at gnome.org> 2010-07-30 05:21:28 PDT ---
(In reply to comment #8)
> In RejectError:
> > is not meaningful, ans SHOULD
> 
> "and"

I fixed the typo in 361b443981dc7550169344bc9c0522152caa36e2

> The conventional pseudocode for dictionaries is to use Python/JSON syntax, in
> which the whole dictionary is wrapped in {}, and items are separated by commas:
> 
>     { 'expected-hostname': 'gmail.com',
>       'certificate-hostname': 'evil.example.org' }
> 
> or 
> 
>     {
>       'expected-hostname': 'gmail.com',
>       'certificate-hostname': 'evil.example.org',
>     }
> 
> or however you want to indent it.

I went for the latter form, and fixed it in
6ae8d8ada1c0550f75111c4c4c438e966edd6715

> Instead of making a new <dl>, I'd prefer including these in the existing <dl>,
> above the <tp:rationale>. Indeed, now that we have a practical use for
> ConnectionErrorDetails, you could delete the "maybe we'll use this in future"
> rationale :-)

This makes sense, I changed it in 565766c307fdba26cf17d29eeb2d9cbb651790e2

> Please do keep all three places in sync. Also, Bug #23931 tries to add Revoked,
> which I hadn't spotted; is that available in all three lists too?
> 
> I believe Vivek called it Insecure rather than Insecure_Algorithm in Bug #23931
> because the algorithm isn't necessarily the part that's insecure: consider
> 256-bit RSA, for instance :-)

Yeah, good point. I synced the three lists in
9c351609b05427552dc669a7a0bc763cf16633c5, which also renames Insecure_Algorithm
to Insecure.

> As I understand it, Limit_Exceeded was intended to represent limits hard-coded
> into GNUTLS, to stop people performing denial of service attacks by providing
> massive certificates that will take hours of computation to verify? It's
> probably more useful as a Connection_Error than here, but we should keep the
> TLS-related things in sync.

By looking at GnuTLS and OpenSSL documentation, it seems those limits are not
hardcoded, and there are APIs to tweak them (e.g. [1]). My take was that it's
kind of pointless to expose that kind of detail in an error, if we can't act on
the limits themselves.

[1]
http://www.gnu.org/software/gnutls/manual/gnutls.html#index-gnutls_005fcertificate_005fset_005fverify_005flimits-100

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.