<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Jérémy
<blockquote cite="mid:1416151621.16441.1.camel@melix.org"
type="cite">
<pre wrap="">I'm pretty amazed the problem comes from openssl.</pre>
</blockquote>
So am i. But after analyzing the problem it really makes sense, let
me try to be more clear.<br>
<br>
<blockquote cite="mid:1416151621.16441.1.camel@melix.org"
type="cite">
<pre wrap="">Did you check upstream openssl ? maybe it's a known bug,
so the "Origin" field could link to it, ideally.</pre>
</blockquote>
I did checked upstream, and the problem exist in the current code. I
also have submitted the same patch to the upstream project.<br>
<br>
After a quick analyze of the current code it seems to be a
regression after commit
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<span style="color: rgb(0, 0, 0); font-size: 12px; font-style:
normal; font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; word-spacing: 0px;
display: inline ! important; float: none; background-color:
rgb(255, 255, 255);">4aac102f75b517bdb56b1bcfd0a856052d559f6e</span>
in which the function
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<span style="color: rgb(0, 0, 0); font-size: small; font-style:
normal; font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; word-spacing: 0px;
display: inline ! important; float: none; background-color:
rgb(255, 255, 255);">EVP_DecryptFinal_ex has been partially
rewritten to avoid timing leak attack.<br>
<br>
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. <br>
<br>
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. <br>
<br>
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.<br>
</span><br>
<br>
<blockquote cite="mid:1416151621.16441.1.camel@melix.org"
type="cite">
<pre wrap="">If it is double-checked with upstream, then this bug report
should be reassigned to openssl package.</pre>
</blockquote>
I'll do it as soon as upstream answer to my bug report.<br>
<br>
Kind regards,
<pre class="moz-signature" cols="72">--
William <a class="moz-txt-link-freetext" href="http://www.wbonnet.net">http://www.wbonnet.net</a>
<a class="moz-txt-link-freetext" href="http://france.debian.net">http://france.debian.net</a> Association Debian France
<a class="moz-txt-link-freetext" href="http://www.opencsw.org">http://www.opencsw.org</a> Community SoftWare for Solaris
</pre>
</body>
</html>