DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=44335>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=44335 ------- Additional Comments From [EMAIL PROTECTED] 2008-02-05 13:17 ------- Well, yes, that's basically what I illustrated in my "ugly workaround". But the only way to currently reset the appropriate values is to call verify (on some bytes, it doesn't matter what). That completes the init/update/verify cycle and leaves the underlying SignatureAlgorithmSpi (really the wrapped java.security.Signature/Mac instance) in a known good state. Re-invoking initVerify(Key) there wouldn't work because it's the source of the problem in the first place. You'd have to pass in the current verification key, b/c that's all you have - and that would be a noop, b/c of the optimization. Those are the only 2 methods that I can see which cause the underlying engine's state to be reset. So other than calling verify on dummy data (less than ideal...), one obvious option is to expose a new method on SignatureAlgorithm, which causes the underlying engine Spi instance to be effectively reset (or recreated?) to a known good state, either prior to or at the time of, the next verification. Another option, which just occurred to me, is for the engine Spi instance to keep track of what state it is in with respect to the init/update/verify cycle (or init/update/sign). The SignatureAlgorithm could then check this state and do the right thing if the engine isn't in the "ready" state. This might be more desirable, because it alleviates the caller (XMLSignature) from having to be sure to reset the engine for all cases where exceptions might encountered in the sign/verify cycles. This would require augmenting the API of the SignatureAlgorithmSpi, however. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
