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 [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=80439 --- shadow/80439 2007-01-04 05:46:12.000000000 -0500 +++ shadow/80439.tmp.25675 2007-01-04 10:38:02.000000000 -0500 @@ -1,13 +1,13 @@ Bug#: 80439 Product: Mono: Class Libraries Version: 1.2 OS: unknown OS Details: -Status: RESOLVED -Resolution: FIXED +Status: REOPENED +Resolution: Severity: Unknown Priority: Normal Component: CORLIB AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] @@ -68,6 +68,26 @@ ------- Additional Comments From [EMAIL PROTECTED] 2007-01-04 05:46 ------- By reducing the input count, it seems to me you won't buffer the right block for next transformation for the special case when you need to KeepLastBlock (not ECB, padding on, decryption). Does your fix work work with two successives transformations for that case? + +------- Additional Comments From [EMAIL PROTECTED] 2007-01-04 10:38 ------- +Well it looks like it's more complex than that (again ;-). The only +time you can call TransformBlock with the "wrong/smaller"(*) value is +at the end of the decryption process (i.e. there cannot be subsequent +calls to TransformBlock, well unless you have a working test case ?). + +(*) I already consider the previous fix "a bug" we introduce to be +compatible with MS implementation. IMO the "right" behaviour is to +thrown an exception. All decryption should (1) use TransformBlock and +finish with (2) a single call to TransformFinalBlock. In fact because +each transform could be different code (and because this case is +undocumented) it has a bug "real-life" chance of not working for +non-Fx provided symmetric algorithms. + +I appreciate your feedback :) but please use the mailing-lists for +discussions about untested/potential issues or (better) open new (or +re-open existing) bugzilla entries for bugs (with sample code showing +the problem). Adding comments to closed issues has a high probability +to get "lost" (as it won't show up in pre-defined queries). _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
