Hi Jérémy > I'm pretty amazed the problem comes from openssl. So am i. But after analyzing the problem it really makes sense, let me try to be more clear.
> Did you check upstream openssl ? maybe it's a known bug, > so the "Origin" field could link to it, ideally. I did checked upstream, and the problem exist in the current code. I also have submitted the same patch to the upstream project. After a quick analyze of the current code it seems to be a regression after commit 4aac102f75b517bdb56b1bcfd0a856052d559f6e in which the function EVP_DecryptFinal_ex has been partially rewritten to avoid timing leak attack. In the code of this function we can see that each time a 0 value is returned the EVPerr function is called to define the error code before returning 0. This happens in every case but one. The one failing for the given NodeJS unit test. In this case the value 0 is not explicitly given to the return call, but is computed with a mask on the padding_good variable. From my understanding this variable has value zero when padding is bad. This happen in case such as decryption with the "wrong key" (not the key for which the message has been encrypted), which is exactly the test case failing in NodeJS. NodeJs is expecting to have this test to fail, which is ok, but it is also checking for the failure reason. Since the EVPerr is not called before returning the computed zero value, openssl return an undefined failure reason. Making the nodejs unit test fail, and the package build fails also. > If it is double-checked with upstream, then this bug report > should be reassigned to openssl package. I'll do it as soon as upstream answer to my bug report. Kind regards, -- William http://www.wbonnet.net http://france.debian.net Association Debian France http://www.opencsw.org Community SoftWare for Solaris
