[Webkit-unassigned] [Bug 162910] [SOUP] Move global TLS errors handling from ResourceHandle to SoupNetworkSession

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=162910

Michael Catanzaro <mcatanzaro at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #290607|review?                     |review-
              Flags|                            |

--- Comment #2 from Michael Catanzaro <mcatanzaro at igalia.com> ---
Comment on attachment 290607
  --> https://bugs.webkit.org/attachment.cgi?id=290607
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=290607&action=review

I know this is a preexisting problem, but please fix it first: either use a secure hash algorithm in HostTLSCertificateSet (e.g. SHA-256 from CryptoDigest.h), or else just stop using hashes there and copy the full certificates into the hash table. This is a sufficiently-minor issue that I don't think we need to get a CVE for it, but it needs fixed.

> Source/WebCore/platform/network/soup/SoupNetworkSession.cpp:67
> +    bool contains(GTlsCertificate* certificate)

Should be const (preexisting issue)

> Source/WebCore/platform/network/soup/SoupNetworkSession.h:68
> +    static void setShouldIgnoreTLSErrors(bool);
> +    static void checkTLSErrors(SoupRequest*, SoupMessage*, std::function<void (const ResourceError&)>&&);
> +    static void allowSpecificHTTPSCertificateForHost(const CertificateInfo&, const String& host);

Why make these static? Doesn't it defeat the point of moving this code to SoupNetworkSession? I would expect different network sessions to handle these independently. If you were planning to change this in a future patch, it'd be better to do it now by using SoupNetworkSession::defaultSession() in NetworkProcessSoup.cpp, and fix up NetworkProcessSoup.cpp in a future patch.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161004/68b7dc61/attachment.html>