Web Inspector: Network: provide a way to accept alternate types of certificate data

[Devin Rousso]

Both the Network agent and `InspectorFrontendHost` use a `CertificateInfo` for encoding/decoding, but other devices/frameworks may not have included the entirety of WebKit (including WebCore), and therefore may only have a smaller subset of the data.  There should be a way to send back other types of certificate data from `Network.getSerializedCertificate` that `InspectorFrontendHost::showCertificate` can then handle.

[Devin Rousso]

Created attachment 370557 [details]
Patch

Rather than create an API for it, this may be a simpler solution for clients using the Security framework.

[EWS Watchlist]

This patch modifies the inspector protocol. Please ensure that any frontend changes appropriately use feature checks for new protocol features.

[Devin Rousso]

Comment on attachment 370557 [details]
Patch

cq-, while we discuss if this is the right way forward

[Devin Rousso]

<rdar://problem/51076339>

[Devin Rousso]

Comment on attachment 370557 [details]
Patch

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

> Source/WebCore/inspector/InspectorFrontendHost.cpp:490
> +    if (type.isEmpty() || type == "WebCore") {

This could use `Inspector::Protocol::InspectorHelpers::getEnumConstantValue(Inspector::Protocol::Security::SerializedCertificateType::WebCore)` instead.

> Source/WebCore/inspector/InspectorFrontendHost.cpp:495
> +    else if (type == "SecTrustRef") {

Ditto (>490).

[BJ Burg]

Comment on attachment 370557 [details]
Patch

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

I am worried about this breaking. How can we test this?

> Source/JavaScriptCore/inspector/protocol/Network.json:209
> +                { "name": "serializedCertificate", "type": "string", "description": "Represents a base64 encoded certificat object." },

Nit: certificate

> Source/WebCore/platform/network/cf/CertificateInfo.h:153
> +static bool decodeSecTrustRefIfAble(Decoder& decoder, RetainPtr<SecTrustRef>& result)

I don't understand the need to shell this out. What's wrong with the existing decodeSecTrustRef?

[Devin Rousso]

Comment on attachment 370557 [details]
Patch

Clearing flags to remove from review queue while we discuss the necessity of this approach.