W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2014

[Bug 23728] CryptoOperationData can be mutated during operation

From: <bugzilla@jessica.w3.org>
Date: Mon, 12 May 2014 03:25:06 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-23728-7213-ztLhJbFS3M@http.www.w3.org/Bugs/Public/>

Ryan Sleevi <sleevi@google.com> changed:

           What    |Removed                     |Added
                 CC|                            |public-webcrypto@w3.org

--- Comment #2 from Ryan Sleevi <sleevi@google.com> ---
So, the Web Audio solution isn't fully applicable here.

Web Audio only takes ArrayBuffer's as inputs, and describes an algorithm that
is not clear if it's actually legal. That is, the algorithm ( from
), is roughly

- Temporarily mark [input buffer] as neutered
- Perform some asynchronous operation
- Restore [input buffer] to it's original, un-neutered state.

That doesn't work for CryptoOperationData, which may take an ArrayBufferView,
for the reasons described in
https://www.khronos.org/registry/typedarray/specs/latest/#9.3 - Cloning an
ArrayBufferView - although the language in ES6 (which is where TypedArrays now
live - http://people.mozilla.org/~jorendorff/es6-draft.html#sec-structured-data
- with the transferrable semantics in

Implementing something like the Typed Array transfer semantics isn't desirable
in general, for consider a use case like digest(). Neutering the original
object forces the copy semantics onto the caller, which then makes memory
management more difficult to reason about (as it relates to reasoning about all
the scopes both the original buffer and its clone are viable in).

In order to resolve this, I've made it explicit that the asynchronous
operations operate on a copy of the data. This was included in the pre-Promises
version of the specification, as well as the "sequence<CryptoOperationData>"

Alternative suggestions are welcome, but probably with accompanying proposed
spec text.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 12 May 2014 03:25:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC