[Mono-bugs] [Bug 80441][Nor] Changed - Case where successive decryption fails using same bytearray

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by sebastien at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=80441

--- shadow/80441	2007-03-06 01:51:36.000000000 -0500
+++ shadow/80441.tmp.19865	2007-03-06 09:51:21.000000000 -0500
@@ -1,13 +1,13 @@
 Bug#: 80441
 Product: Mono: Class Libraries
 Version: 1.2
 OS: unknown
 OS Details: 
-Status: NEW   
-Resolution: 
+Status: RESOLVED   
+Resolution: WONTFIX
 Severity: Unknown
 Priority: Normal
 Component: CORLIB
 AssignedTo: sebastien at ximian.com                            
 ReportedBy: lauren.bedoule at gmail.com               
 QAContact: mono-bugs at ximian.com
@@ -57,6 +57,25 @@
 
 Additional Information:
 Test fails under M$ too, yet with a different output. It seems their
 implementation is buggy too, as soon as you use same object as input and
 output. But I let you send the bug to them...
 I still have a doubt with this test. Let me know if it's invalid.
+
+------- Additional Comments From sebastien at ximian.com  2007-03-06 09:51 -------
+The test fails (under MS and Mono) because there's no guarantee, by
+the API, of what happens if the source buffer (input) is the same as
+the destination (output). I.e. the input buffer is considered
+read-only while the output buffer is considered write-only. Using
+input == output breaks this assumption. How it breaks depends on the
+implementation (different from MS and Mono and you can expect changes
+in the future).
+
+Possible solutions are
+(1) change the transform code to copy all the input data; 
+(2) change the transform code to detect input==output and copy this data;
+(3) change your code to ensure input!=output by allocation/copying
+memory if required.
+
+We won't do (1) and (2), for the same reason MS doesn't, as both cases
+would slow down the cryptographic operations (more allocation, more GC
+work) for a use case that is, at best, very uncommon.