[Webkit-unassigned] [Bug 163166] [GStreamer] Certificate database missing when accessing HTTPS via WebKitWebSourceGStreamer

[bugzilla-daemon at webkit.org]

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

Carlos Garcia Campos <cgarcia at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cgarcia at igalia.com
            Summary|REGRESSION(r202615):        |[GStreamer] Certificate
                   |[GStreamer] Certificate     |database missing when
                   |database missing when       |accessing HTTPS via
                   |accessing HTTPS via         |WebKitWebSourceGStreamer
                   |WebKitWebSourceGStreamer    |

--- Comment #3 from Carlos Garcia Campos <cgarcia at igalia.com> ---
This is not a regression of r202615, In r202615 we only moved loads that are started in a secondary thread to another secondary thread to avoid deadlocks because of the GST locks. But before, those loas were still done in the web process using a ResourceHandle, but in the main thread. Ideally, we would not be doing those loads at all, but since our source element is public (and can't be made private with current GST APIs), we end up doing those loads. Because of that we have this second path were we use a ResourceHandle to do the loads like the souphttpsrc element would do. HLS code in GST uses a source element to download the manifest and fragments, but when using the souphttpsrc element, it also rejects connections to invalid certificates, because souphttpsrc uses ssl strict by default. So, I don't think we should be using the TLS exceptions added via API for these loads, because they don't belong to WebKit, but to GST. What I think that could have happened is that we removed the n

-- 
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/20161010/42af764a/attachment.html>