- From: <bugzilla@jessica.w3.org>
- Date: Wed, 18 Jun 2014 01:07:29 +0000
- To: public-script-coord@w3.org
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