Open Bug 737451 Opened 13 years ago Updated 3 years ago

enhance updateFromStream in crypto hashing to support 64-bit sized input

Categories

(Core :: Security, defect)

x86_64
Linux
defect

Tracking

()

People

(Reporter: m_kato, Assigned: m_kato)

References

Details

Attachments

(1 file)

No description provided.
Blocks: 215450
No longer depends on: 215450
Attached patch fixSplinter Review
testing on try server
Attachment #607579 - Flags: review?(kaie)
Summary: updateFromStream makes 64-bit → enhance updateFromStream in crypto hashing to support 64-bit sized input
Comment on attachment 607579 [details] [diff] [review] fix I propose Honza reviews this code first, as he wrote it initially.
Attachment #607579 - Flags: superreview?(kaie)
Attachment #607579 - Flags: review?(kaie)
Attachment #607579 - Flags: review?(honzab.moz)
Comment on attachment 607579 [details] [diff] [review] fix Review of attachment 607579 [details] [diff] [review]: ----------------------------------------------------------------- According bug 215450 comment 87, followup means something to create and land after the main thing. I don't think this change is good to do before. This obsoletes the security patch in that bug anyway. Lot of things in this patch are not necessary for bug 215450 so I don't see much reason to land it first when the claim the API offers cannot be satisfied anyway. ::: browser/app/profile/extensions/testpilot@labs.mozilla.com/modules/jar-code-store.js @@ +108,5 @@ > .createInstance(Ci.nsICryptoHash); > // Use SHA256, it's more secure than MD5: > ch.init(ch.SHA256); > // this tells updateFromStream to read the entire file > + ch.updateFromStream(istream, istream.available()); Why not to pass 0xffffffffffffffff ? PR_Available64 that istram.available() calls may be expensive. Why did -1 (in other places of calls) didn't work? ::: security/manager/ssl/src/nsStreamCipher.cpp @@ +152,5 @@ > + aLen = PR_UINT32_MAX; > + > + // NS_ConsumeStream doesn't allow over 4GB length > + if (aLen > PR_UINT32_MAX) > + return NS_ERROR_FILE_TOO_BIG; r- for this: Sorry, but this appears to me strange. You are changing the API to allow 64 bit length, but actually don't support it in the implementation. Also NS_ConsumeStream won't accept 64 bits for maxCount in your xpcom patch from bug 215450. ::: toolkit/mozapps/extensions/PluginProvider.jsm @@ +69,5 @@ > hasher.init(Ci.nsICryptoHash.MD5); > let stringStream = Cc["@mozilla.org/io/string-input-stream;1"]. > createInstance(Ci.nsIStringInputStream); > stringStream.data = aStr ? aStr : "null"; > + hasher.updateFromStream(stringStream, stringStream.available()); As above. ::: toolkit/mozapps/plugins/content/pluginInstallerService.js @@ +65,5 @@ > > var hasher = Components.classes['@mozilla.org/security/hash;1']. > createInstance(Components.interfaces.nsICryptoHash); > hasher.initWithString(method); > + hasher.updateFromStream(fis, fis.available()); As above. ::: toolkit/mozapps/update/nsUpdateService.js @@ +2579,5 @@ > var hashFunction = Ci.nsICryptoHash[this._patch.hashFunction.toUpperCase()]; > if (hashFunction == undefined) > throw Cr.NS_ERROR_UNEXPECTED; > hash.init(hashFunction); > + hash.updateFromStream(fileStream, fileStream.available()); As above.
Attachment #607579 - Flags: review?(honzab.moz) → review-
Attachment #607579 - Flags: superreview?(kaie)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: