On Nov 6, 2007 2:12 AM, Atsuhiko Yamanaka <[EMAIL PROTECTED]> wrote:
>
> +-From: "Jerome Lacoste" <[EMAIL PROTECTED]> --
> |_Date: Mon, 5 Nov 2007 18:39:50 +0100 _______________
> |
> |I've finally managed to get a full stack trace:
> |[#|2007-11-05T18:23:
> |00.980+0100|WARNING|sun-
> appserver-ee8.1_02|javax.enterprise.system.stream.err|_ThreadID=230
> |;|
> |javax.crypto.ShortBufferException: 32 needed, 20480 supplied
> | at
> org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.engineUpdate(
> |JSSCipherSpi.java:338)
> | at javax.crypto.Cipher.update(DashoA12275)
>
> Sign, I knew.
>
> Before writing my last message, I had found the following buggy code[1],
>
> public int engineUpdate(byte[] input, int inputOffset, int inputLen,
> byte[] output, int outputOffset) throws ShortBufferException
> {
> byte[] bytes = engineUpdate(input, inputOffset, inputLen);
> if( bytes.length < output.length-outputOffset ) {
> throw new ShortBufferException(bytes.length + " needed, " +
> (output.length-outputOffset) + " supplied");
> }
> System.arraycopy(bytes, 0, output, outputOffset, bytes.length);
> return bytes.length;
> }
>
> and I had strongly believed that the problem had come from it,
> but it is contradict to your success with your own compiled jar.
>
>
> [1]
> http://www.koders.com/java/fidF0D62D7385480B906B3CC88210B02AF4A84FF467.aspx
>
OK now I have some time to try to fix this problem.
Should I consider this to be a bug in the cipher implementation of the
mozilla security library ?
It looks like in the call from Session line 800 specified both the input and
output buffer so the issue should come from there, right ?
c2scipher.update(buf, 0, packet.buffer.index, buf, 0);
Why is the last parameter 0 ? shouldn't it be buf.length ?
if the problem doesn't lie in jsch, does jsch need this cipher in the first
place ? How is it picked up ? I can successfully transfer files from my
machine (where the environment classpath is of course different) but I am
not yet sure if I can remove this one from the application server classpath.
Is there a way for me to force jsch to ignore this cipher for SFTP ?
Thanks a lot for your help,
Cheers,
Jerome
is just a consequence of a problem that exists before. The engineUpdate code
that throws the exception looks OK to me.
As the too small buffer that is receives is passed through javax.crypto by
TripleDESCBC from the jsch Session object, should I conclude that the
problem comes from jsch ? or is
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
JSch-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jsch-users
