Bug#768681: [Pkg-openssl-devel] Bug#768681: Bug#768681: nodejs: FTBFS in jessie: tests failures
reopen 768681 severity 768681 important thanks On Wed, Dec 17, 2014 at 08:02:30AM +0100, Paul Gevers wrote: On 16-12-14 22:53, Kurt Roeckx wrote: Which upstream? I meant openssl, as I thought William was referring to that. Upsteam openssl is saying that this is intentional behaviour, and as such I won't be fixing this. Ok. So I suggest to tag this bug as wontfix, and depending on how you as a team handle wontfixes, also close the bug. So it seems that they just decided to revert that change since more people run into it. But I still suggest nodejs gets fixed. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768681: nodejs: FTBFS in jessie: tests failures
Control: tags -1 patch Hi William On Sun, 16 Nov 2014 18:28:05 +0100 William Bonnet will...@wbonnet.net wrote: 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. I tried to find the openssl bug you seem to refer to, but I couldn't find it. If you made one, it would be great to use the Forwarded control tag to keep a link to it. It would help to get this (RC) bug further by knowing the stance of upstream. Also, I am not sure that the current bug is really RC. What is the justification for it? Paul signature.asc Description: OpenPGP digital signature
Bug#768681: [Pkg-openssl-devel] Bug#768681: nodejs: FTBFS in jessie: tests failures
On Tue, Dec 16, 2014 at 10:15:51PM +0100, Paul Gevers wrote: Control: tags -1 patch Hi William On Sun, 16 Nov 2014 18:28:05 +0100 William Bonnet will...@wbonnet.net wrote: 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. I tried to find the openssl bug you seem to refer to, but I couldn't find it. If you made one, it would be great to use the Forwarded control tag to keep a link to it. It would help to get this (RC) bug further by knowing the stance of upstream. Which upstream? Upsteam openssl is saying that this is intentional behaviour, and as such I won't be fixing this. Also, I am not sure that the current bug is really RC. What is the justification for it? I assume the FTBFS of nodejs makes this an RC bug for nodejs. It cleary is not an RC bug in openssl. I suggest we just reassign this to nodejs? Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768681: [Pkg-openssl-devel] Bug#768681: nodejs: FTBFS in jessie: tests failures
On 16-12-14 22:53, Kurt Roeckx wrote: Which upstream? I meant openssl, as I thought William was referring to that. Upsteam openssl is saying that this is intentional behaviour, and as such I won't be fixing this. Ok. So I suggest to tag this bug as wontfix, and depending on how you as a team handle wontfixes, also close the bug. Also, I am not sure that the current bug is really RC. What is the justification for it? I assume the FTBFS of nodejs makes this an RC bug for nodejs. It cleary is not an RC bug in openssl. That was also my judgment. So I suggest to lower the severity as well. Although, if you close the bug, that won't be necessary. I suggest we just reassign this to nodejs? nodejs already has an RC bug for this (#766484) including a patch. Paul signature.asc Description: OpenPGP digital signature
Bug#768681: nodejs: FTBFS in jessie: tests failures
Hi,
I would like to submit a patch to openssl in order to fix this issue. This
patch is fixing a missing error code in the EVP_DecryptFinal_ex function
which cause the failure of the NodeJS unit test.
During the latest Debian Bug Squashing Party i was working on NodeJS
packaging with Jean Baptiste Favre and trying to fix some issues. We noticed
a unit test failure (on NodeJS side) because of an unexpected openssl return
value.
Unit test is simple/test-crypto-stream, and is based on aes-128-cbc
encryption and decryption with two different keys. This test should fail
with the error code :
[TypeError: error:06065064:digital envelope
routines:EVP_DecryptFinal_ex:bad decrypt]
But the latest stable version of openssl returns
[TypeError: error::lib(0):func(0):reason(0)]
This seems to come from some modification made in the
EVP_DecryptFinal_ex function in the last version bump. When returning
padding_good,
the EVPerr is not called before returning zero, leading to an undefined error
code.
Here attached is a patch fixing this.
I hope this will help, don't hesitate to ask me for more information.
Please, as it is my first submission let me know if some is wrong in the way to
do it
Kind regards,
--
William http://www.wbonnet.net
http://france.debian.netAssociation Debian France
http://www.opencsw.org Community SoftWare for Solaris
diff -Nru openssl-1.0.1j/debian/changelog openssl-1.0.1j/debian/changelog
--- openssl-1.0.1j/debian/changelog 2014-10-15 19:42:52.0 +0200
+++ openssl-1.0.1j/debian/changelog 2014-11-16 13:49:49.0 +0100
@@ -1,3 +1,11 @@
+openssl (1.0.1j-2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload
+- Fix for missing Bad Decrypt error code in EVP_DecryptFinal_ex when padding is not good
+ (Closes #768681)
+
+ -- William Bonnet wllmb...@gmail.com Sun, 16 Nov 2014 13:46:13 +0100
+
openssl (1.0.1j-1) unstable; urgency=high
* New upstream release
diff -Nru openssl-1.0.1j/debian/patches/EVP_DecryptFinal_ex_missing_EVPerr_call.patch openssl-1.0.1j/debian/patches/EVP_DecryptFinal_ex_missing_EVPerr_call.patch
--- openssl-1.0.1j/debian/patches/EVP_DecryptFinal_ex_missing_EVPerr_call.patch 1970-01-01 01:00:00.0 +0100
+++ openssl-1.0.1j/debian/patches/EVP_DecryptFinal_ex_missing_EVPerr_call.patch 2014-11-16 13:55:32.0 +0100
@@ -0,0 +1,38 @@
+Description: Fix for missing Bad Decrypt error code in EVP_DecryptFinal_ex
+ EVP_DecryptFinal_ex function. When returning padding_good, the EVPerr is
+ not called before returning zero, leading to an undefined error code.
+ .
+ openssl (1.0.1j-2) UNRELEASED; urgency=medium
+ .
+ * Non-maintainer upload
+ - Fix for missing Bad Decrypt error code in EVP_DecryptFinal_ex when padding is not good
+ (Closes #768681)
+Author: William Bonnet wllmb...@gmail.com
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: other
+Bug-Debian: https://bugs.debian.org/768681
+
+--- openssl-1.0.1j.orig/crypto/evp/evp_enc.c
openssl-1.0.1j/crypto/evp/evp_enc.c
+@@ -555,6 +555,16 @@ int EVP_DecryptFinal_ex(EVP_CIPHER_CTX *
+ out[i] = ctx-final[i] padding_good;
+ /* Safe cast: for a good padding, EVP_MAX_IV_LENGTH = b = pad */
+ *outl = padding_good ((unsigned char)(b - pad));
++
++ /*
++ * If the padding_good variable is 0 then a decryption problem occured
++ * and we have to call EVPerr before returning 0
++ */
++ if ((padding_good 1) == 0)
++ {
++EVPerr(EVP_F_EVP_DECRYPTFINAL_EX, EVP_R_BAD_DECRYPT);
++ }
++
+ return padding_good 1;
+ }
+ else
diff -Nru openssl-1.0.1j/debian/patches/series openssl-1.0.1j/debian/patches/series
--- openssl-1.0.1j/debian/patches/series 2014-10-15 19:34:35.0 +0200
+++ openssl-1.0.1j/debian/patches/series 2014-11-16 13:53:21.0 +0100
@@ -22,3 +22,4 @@
openssl_fix_for_x32.patch
ppc64el.patch
+EVP_DecryptFinal_ex_missing_EVPerr_call.patch
signature.asc
Description: OpenPGP digital signature
Bug#768681: nodejs: FTBFS in jessie: tests failures
Le dimanche 16 novembre 2014 à 14:43 +0100, William Bonnet a écrit : Hi, I would like to submit a patch to openssl in order to fix this issue. This patch is fixing a missing error code in the EVP_DecryptFinal_ex function which cause the failure of the NodeJS unit test. During the latest Debian Bug Squashing Party i was working on NodeJS packaging with Jean Baptiste Favre and trying to fix some issues. We noticed a unit test failure (on NodeJS side) because of an unexpected openssl return value. Unit test is simple/test-crypto-stream, and is based on aes-128-cbc encryption and decryption with two different keys. This test should fail with the error code : [TypeError: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt] But the latest stable version of openssl returns [TypeError: error::lib(0):func(0):reason(0)] This seems to come from some modification made in the EVP_DecryptFinal_ex function in the last version bump. When returning padding_good, the EVPerr is not called before returning zero, leading to an undefined error code. Here attached is a patch fixing this. I hope this will help, don't hesitate to ask me for more information. Please, as it is my first submission let me know if some is wrong in the way to do it I'm pretty amazed the problem comes from openssl. Did you check upstream openssl ? maybe it's a known bug, so the Origin field could link to it, ideally. If it is double-checked with upstream, then this bug report should be reassigned to openssl package. Jérémy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768681: nodejs: FTBFS in jessie: tests failures
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.netAssociation Debian France http://www.opencsw.org Community SoftWare for Solaris
Bug#768681: nodejs: FTBFS in jessie: tests failures
On Sun, Nov 16, 2014 at 06:28:05PM +0100, William Bonnet wrote: 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. I think not returning which error occurred is actually intentional, since you might leak that information and turn it into a padding oracle. But I'll check what the others thinks. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768681: nodejs: FTBFS in jessie: tests failures
Hi Kurt I think not returning which error occurred is actually intentional, since you might leak that information and turn it into a padding oracle. But I'll check what the others thinks Thanks for the feedback. I have thought of the padding oracle attack, but since all others errors have a distinct return code, having no return code would be close to having the proper return code, since it can happen in only this case. Well at least that's my understanding, and since i'm not a crypto guy I'm really interested in the answer from the real experts :) Kind regards, -- William http://www.wbonnet.net http://france.debian.netAssociation Debian France http://www.opencsw.org Community SoftWare for Solaris -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768681: nodejs: FTBFS in jessie: tests failures
Hello, We had a look on it during Debian BSP in Paris this week-end. As commented in bug #766484 [1], this test fails since last openssl upgrade to 1.0.1j-1. I used debsnap to downgrade libssl-dev and libssl1.0.0. Build is successfull up to libssl-dev 1.0.1i. A patch [2] has been provided upstream for 0.10.33 release of nodejs. But since the patch hasn't been merged into upstream master branch, I'm sure it's a good idea to include it in the Debian package. Regards, Jean Baptiste [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766484#15 [2] https://github.com/joyent/node/commit/707cc25011d142fe4ade14ce2aa083a96ef15bcb signature.asc Description: OpenPGP digital signature
Bug#768681: nodejs: FTBFS in jessie: tests failures
Source: nodejs Version: 0.10.29~dfsg-1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20141108 qa-ftbfs Justification: FTBFS in jessie on amd64 Hi, During a rebuild of all packages in jessie (in a jessie chroot, not a sid chroot), your package failed to build on amd64. Relevant part (hopefully): make[2]: Entering directory '/«PKGBUILDDIR»/out' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/«PKGBUILDDIR»/out' ln -fs out/Release/node node /usr/bin/python tools/test.py --arch=x64 simple [00:00|% 0|+ 0|- 0]: release test-abort-fatal-error [00:00|% 0|+ 1|- 0]: release test-arraybuffer-slice [00:00|% 0|+ 2|- 0]: release test-assert [00:00|% 0|+ 3|- 0]: release test-bad-unicode [00:00|% 0|+ 4|- 0]: release test-buffer [00:00|% 0|+ 5|- 0]: release test-buffer-ascii [00:00|% 0|+ 6|- 0]: release test-buffer-concat [00:00|% 1|+ 7|- 0]: release test-buffer-regress-GH-2659 [00:00|% 1|+ 8|- 0]: release test-c-ares [00:01|% 1|+ 9|- 0]: release test-chdir [00:01|% 1|+ 10|- 0]: release test-child-process-buffering [00:01|% 1|+ 11|- 0]: release test-child-process-customfd-bounded [00:01|% 1|+ 12|- 0]: release test-child-process-cwd [00:01|% 2|+ 13|- 0]: release test-child-process-detached [00:01|% 2|+ 14|- 0]: release test-child-process-disconnect [00:01|% 2|+ 15|- 0]: release test-child-process-double-pipe [00:01|% 2|+ 16|- 0]: release test-child-process-env [00:02|% 2|+ 17|- 0]: release test-child-process-exec-cwd [00:02|% 2|+ 18|- 0]: release test-child-process-exec-env [00:02|% 3|+ 19|- 0]: release test-child-process-exec-error [00:02|% 3|+ 20|- 0]: release test-child-process-exit-code [00:02|% 3|+ 21|- 0]: release test-child-process-fork [00:02|% 3|+ 22|- 0]: release test-child-process-fork-and-spawn [00:02|% 3|+ 23|- 0]: release test-child-process-fork-close [00:03|% 3|+ 24|- 0]: release test-child-process-fork-dgram [00:03|% 4|+ 25|- 0]: release test-child-process-fork-exec-argv [00:03|% 4|+ 26|- 0]: release test-child-process-fork-exec-path [00:04|% 4|+ 27|- 0]: release test-child-process-fork-getconnections [00:04|% 4|+ 28|- 0]: release test-child-process-fork-net [00:04|% 4|+ 29|- 0]: release test-child-process-fork-net2 [00:04|% 4|+ 30|- 0]: release test-child-process-fork-ref [00:05|% 5|+ 31|- 0]: release test-child-process-fork-ref2 [00:05|% 5|+ 32|- 0]: release test-child-process-fork3 [00:05|% 5|+ 33|- 0]: release test-child-process-internal [00:06|% 5|+ 34|- 0]: release test-child-process-ipc [00:06|% 5|+ 35|- 0]: release test-child-process-kill [00:06|% 5|+ 36|-
