Bug 133863 – [iOS] Networking process always decodes keys

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[iOS] Networking process always decodes keys

Created attachment 233058 [details]
Disallow decoding keys by default

[Anders Carlsson]

Comment on attachment 233058 [details]
Disallow decoding keys by default

I think "decoding keys" is too vague. How about decoding keychain keys or keychain items?

(In reply to comment #2)
> (From update of attachment 233058 [details])
> I think "decoding keys" is too vague. How about decoding keychain keys or keychain items?

I’m going to change this to setAllowsDecodingSecKeyRef etc.

[Anders Carlsson]

Comment on attachment 233058 [details]
Disallow decoding keys by default

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

r=me with the naming change we discussed.

> Source/WebKit2/Shared/cf/ArgumentCodersCF.cpp:649
> +    if (keyDecodingAllowed)
> +        SecKeyFindWithPersistentRef(keyData.get(), &key);

Will this do the right thing if key decoding is disallowed? Shouldn't it just return false in that case?

(In reply to comment #4)
> (From update of attachment 233058 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=233058&action=review
> 
> r=me with the naming change we discussed.
> 
> > Source/WebKit2/Shared/cf/ArgumentCodersCF.cpp:649
> > +    if (keyDecodingAllowed)
> > +        SecKeyFindWithPersistentRef(keyData.get(), &key);
> 
> Will this do the right thing if key decoding is disallowed? Shouldn't it just return false in that case?

Leaving key set to nullptr will follow the code path we already take when we don’t have access to the key for any other reason (such as, on Mac, the user denying access through the Security dialog, or on both platforms the case where the key has been deleted between when it was sent and when it was received).

Fixed in <http://trac.webkit.org/r169938>.