W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2014

[Bug 23369] Provide hooks for Typed Arrays (ArrayBuffer and friends)

From: <bugzilla@jessica.w3.org>
Date: Wed, 18 Jun 2014 01:07:29 +0000
To: public-script-coord@w3.org
Message-ID: <bug-23369-3890-ZklhhBuEOj@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369

--- Comment #25 from Allen Wirfs-Brock <allen@wirfs-brock.com> ---
(In reply to Ryan Sleevi from comment #24)

I'll be short.  Didn't really mean to have a debate.
> 
> I don't know what you mean by "an integrity issue". Modifying a buffer
> during verify, for example, can cause a different message to be verified
> than intended. Modifying a message during decrypt might allow an invalid
> message to be treated as valid, thus causing all sorts of cryptographic bugs.

By "integrity issue" I primarily mean an issue that exposes otherwise
inaccessible information or functionality.

Decrypting the wrong text because of a caller error sounds like a bug, not an
integrity issue.  Leaking knowledge that allowed a secret key to be inferred
would be an integrity issue.

> 
> This is not about being nannies. This is about being responsible spec
> authors and defining sensible memory models and pseudo-threading semantics,
> rather than being blaise and saying "Don't do that". The term "undefined
> behaviour" should be the last refuge of the spec author, not the first.
> 
Processor and (particularly) memory cycles are valuable things.  I'm not sure
that requiring non-essential buffer copying in responsible spec authoring. My
experience is that pervasively doing such things bogs down systems.  It's not
any single copy or redundant check that's the problem is the collective effect
of millions of them at runtime.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 18 June 2014 01:07:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC