W3C home > Mailing lists > Public > public-webcrypto@w3.org > February 2016

[Bug 29437] Parsing a JWK can have side-effects if not done very carefully

From: <bugzilla@jessica.w3.org>
Date: Tue, 09 Feb 2016 02:02:05 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-29437-7213-h3EuycXcGq@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29437

Ryan Sleevi <sleevi@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sleevi@google.com

--- Comment #3 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Boris Zbarsky from comment #2)
> I'm somewhat interested in _not_ requiring creation of a separate global
> here, honestly...  It seems like a good bit of overhead for no particularly
> good reason.

The carefully written reviver function would be black-box indistinguishable
from a separate global, right?

(Apologies, I don't fully understand the intricacies of the JS state at play
here)

The main goal was to ensure that the JWK handling (for wrapping or unwrapping)
didn't require a round-trip back into the caller's script, since they may (or
the JWK sender may) have sent with an extractable=false, and a round-trip
through user code/state would end up violating that.

Well, that, and to fully ensure that the JWK handling could be fully run on
another thread (or more aptly, arbitrary threads) without having to worry about
blocking on the main task loop of the page.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 9 February 2016 02:02:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 9 February 2016 02:02:09 UTC