Zinc SSL Exception: decrypt failed code:5
Locked
Zinc SSL Exception: decrypt failed code:5
 
|
Hi Sven,
Hi all, I try to send a curl command (which works at command line) from Pharo. I get the error: "SSL Exception: decrypt failed code:5" The working command line command is: curl -v -H 'Accept: application/json' -u 'aUser:aPassword' 'https://user.xxx.net/oauth/token?grant_type=client_credentials' the result is something like: {"access_token":"a31xxxa-2a22-4xx6c-938d-2bd3ae4a0629","token_type":"bearer","expires_in":42095,"scope":"write"} My current Pharo code is: | theZnClient | theZnClient := ZnClient new systemPolicy ; https; host: 'user.xxx.net'; path: 'oauth/token?grant_type=client_credentials'; username: 'aUser' password: 'aPassword'; accept: ZnMimeType applicationJson; get. theZnClient inspect close. 'aPassword' and 'aUser' and xxx.net was replaced by me for security reasons. In Pharo, I get a walkback with the error message 'SSL Exception: decrypt failed [code:-5]' But I see, that the ZdcSecureSocketStream has the correct result ({"access_token":...":"write"}) in its collection attribute at utf-8 string and at latin1-string so, the request is done and the result is available but then it fails here: ZdcSecureSocketStream(Object)>>error: ZdcSecureSocketStream>>sslException:code: ZdcSecureSocketStream>>fillBytes:startingAt:count: in Block: [ ... ZdcSecureSocketStream>>fillBytes:startingAt:count: ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBufferNoWait ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer ZdcSecureSocketStream(ZdcOptimizedSocketStream)>>readInto:startingAt:count: ZnUTF8Encoder>>optimizedReadInto:startingAt:count:fromStream: ZnUTF8Encoder>>readInto:startingAt:count:fromStream: Sven, I could send you the 'aPassword' and 'aUser' and the url by private message. It would be fine if you could have a short look at it. Regards Sabine |
Re: Zinc SSL Exception: decrypt failed code:5
|
|
Hi Sven,
Hi all, I try to send a curl command (which works at command line) from Pharo. I get the error: "SSL Exception: decrypt failed code:5" The working command line command is: curl -v -H 'Accept: application/json' -u 'aUser:aPassword' 'https://user.xxx.net/oauth/token?grant_type=client_credentials' the result is something like: {"access_token":"a31xxxa-2a22-4xx6c-938d-2bd3ae4a0629","token_type":"bearer","expires_in":42095,"scope":"write"} My current Pharo code is: | theZnClient | theZnClient := ZnClient new systemPolicy ; https; host: 'user.xxx.net'; path: 'oauth/token?grant_type=client_credentials'; username: 'aUser' password: 'aPassword'; accept: ZnMimeType applicationJson; get. theZnClient inspect close. 'aPassword' and 'aUser' and xxx.net was replaced by me for security reasons. In Pharo, I get a walkback with the error message 'SSL Exception: decrypt failed [code:-5]' But I see, that the ZdcSecureSocketStream has the correct result ({"access_token":...":"write"}) in its collection attribute at utf-8 string and at latin1-string so, the request is done and the result is available but then it fails here: ZdcSecureSocketStream(Object)>>error: ZdcSecureSocketStream>>sslException:code: ZdcSecureSocketStream>>fillBytes:startingAt:count: in Block: [ ... ZdcSecureSocketStream>>fillBytes:startingAt:count: ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBufferNoWait ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer ZdcSecureSocketStream(ZdcOptimizedSocketStream)>>readInto:startingAt:count: ZnUTF8Encoder>>optimizedReadInto:startingAt:count:fromStream: ZnUTF8Encoder>>readInto:startingAt:count:fromStream: Sven, I could send you the 'aPassword' and 'aUser' and the url by private message. It would be fine if you could have a short look at it. Regards Sabine |
Re: Zinc SSL Exception: decrypt failed code:5
|
Sabine,
> On 27 Feb 2015, at 16:36, Sabine Manaa <[hidden email]> wrote: > > Hi Sven, > Hi all, > > I try to send a curl command (which works at command line) from Pharo. > I get the error: "SSL Exception: decrypt failed code:5" > > The working command line command is: > > curl -v -H 'Accept: application/json' -u 'aUser:aPassword' > 'https://user.xxx.net/oauth/token?grant_type=client_credentials' > > the result is something like: > {"access_token":"a31xxxa-2a22-4xx6c-938d-2bd3ae4a0629","token_type":"bearer","expires_in":42095,"scope":"write"} > > My current Pharo code is: > | theZnClient | > theZnClient := ZnClient new > systemPolicy ; > https; > host: 'user.xxx.net'; > path: 'oauth/token?grant_type=client_credentials'; > username: 'aUser' password: 'aPassword'; > accept: ZnMimeType applicationJson; > get. > theZnClient inspect close. > > 'aPassword' and 'aUser' and xxx.net was replaced by me for security reasons. > > In Pharo, I get a walkback with the error message > 'SSL Exception: decrypt failed [code:-5]' > > But I see, that the ZdcSecureSocketStream has the correct result > ({"access_token":...":"write"}) in its collection attribute at > utf-8 string and at latin1-string > > so, the request is done and the result is available but then it fails here: > ZdcSecureSocketStream(Object)>>error: > ZdcSecureSocketStream>>sslException:code: > ZdcSecureSocketStream>>fillBytes:startingAt:count: in Block: [ ... > ZdcSecureSocketStream>>fillBytes:startingAt:count: > ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBufferNoWait > ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer > ZdcSecureSocketStream(ZdcOptimizedSocketStream)>>readInto:startingAt:count: > ZnUTF8Encoder>>optimizedReadInto:startingAt:count:fromStream: > ZnUTF8Encoder>>readInto:startingAt:count:fromStream: > > Sven, I could send you the 'aPassword' and 'aUser' and the url by private > message. It would be fine if you could have a short look at it. The fact that there is readable text in the buffer of the ZdcSecureSocketStream is good, because it means that things basically work. One reason why this is failing might be that Zn tries to read more than there is available in the stream, when the content-length does not match. Encoding problems could be part of the problem too. Could you compare curl -v or curl -D - output with the request/response headers in Pharo ? Look for content-length and compare that with what it already read or not. Is the connection kept alive ? Also look at content-type and see if there is any charset encoding after application/json. Sven > Regards > Sabine > > > > -- > View this message in context: http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808345.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > |
Re: Zinc SSL Exception: decrypt failed code:5
|
|
Hi Sven,
thank you for your hints. Indeed, the variable @in of ZdcSecureSocketStream has the string "ZnInvalidUTF8: Illegal leading byte for utf-8 encoding" in its utf-8 variable. Can you tell me, what to add to the pharo code that the encoding is correct/so that is equal to the curl command? comparison of headers: they seem to be equal, also the content type is in both cases 'application/json;charset=UTF-8' The ZnResponse headers: a ZnHeaders( same 'Cache-Control'->#('no-cache, no-store, max-age=0, must-revalidate' 'no-store') same 'Connection'->'close' same 'Content-Type'->'application/json;charset=UTF-8' same 'Date'->'Fri, 27 Feb 2015 20:02:40 GMT' same 'Expires'->'0' same 'Pragma'->#('no-cache' 'no-cache') same 'Set-Cookie'->'crbid=10.1.8.3:49247_mt03.prod.gini.net; path=/' same 'Strict-Transport-Security'->'max-age=31536000 ; includeSubDomains' same 'X-Application-Context'->'0.3:8080' same 'X-Content-Type-Options'->'nosniff' same 'X-Frame-Options'->'DENY' same 'X-Xss-Protection'->'1; mode=block' ) result of curl command at command line < HTTP/1.1 200 OK same < Date: Fri, 27 Feb 2015 17:58:37 GMT same < X-Content-Type-Options: nosniff same < X-XSS-Protection: 1; mode=block same < Cache-Control: no-cache, no-store, max-age=0, must-revalidate same < Pragma: no-cache same < Expires: 0 same < Strict-Transport-Security: max-age=31536000 ; includeSubDomains same < X-Frame-Options: DENY same < X-Application-Context: 0.3:8080 < Cache-Control: no-store < Pragma: no-cache same < Content-Type: application/json;charset=UTF-8 same < Connection: close same < Set-Cookie: crbid=10.1.8.5:49387_mt05.prod.gini.net; path=/ regards sabine 2015-02-27 16:58 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]>: Sabine, |
Re: Zinc SSL Exception: decrypt failed code:5
|
|
> On 27 Feb 2015, at 21:18, Sabine Manaa <[hidden email]> wrote: > > Hi Sven, > > thank you for your hints. > > Indeed, the variable @in of ZdcSecureSocketStream has the string "ZnInvalidUTF8: Illegal leading byte for utf-8 encoding" in its utf-8 variable. That is normal: the in buffer contains encrypted binary data, the out buffer will contain the cleartext (but still in binary). > Can you tell me, what to add to the pharo code that the encoding is correct/so that is equal to the curl command? I don't think there is an encoding problem: the charset is set to utf-8 which will be picked up. Besides, the returned content is plain ascii anyway. The issue is probably the Connection:close and the missing Content-Length. This means that the HTTPS stream has to be read until the end. I have seen this fail in the past in rare cases. Are you on Windows ? Could you try on Linux ? > comparison of headers: they seem to be equal, also the content type is in both cases 'application/json;charset=UTF-8' > The ZnResponse headers: > a ZnHeaders( > same 'Cache-Control'->#('no-cache, no-store, max-age=0, must-revalidate' 'no-store') > same 'Connection'->'close' > same 'Content-Type'->'application/json;charset=UTF-8' > same 'Date'->'Fri, 27 Feb 2015 20:02:40 GMT' > same 'Expires'->'0' > same 'Pragma'->#('no-cache' 'no-cache') > same 'Set-Cookie'->'crbid=10.1.8.3:49247_mt03.prod.gini.net; path=/' > same 'Strict-Transport-Security'->'max-age=31536000 ; includeSubDomains' > same 'X-Application-Context'->'0.3:8080' > same 'X-Content-Type-Options'->'nosniff' > same 'X-Frame-Options'->'DENY' > same 'X-Xss-Protection'->'1; mode=block' ) > > result of curl command at command line > < HTTP/1.1 200 OK > same < Date: Fri, 27 Feb 2015 17:58:37 GMT > same < X-Content-Type-Options: nosniff > same < X-XSS-Protection: 1; mode=block > same < Cache-Control: no-cache, no-store, max-age=0, must-revalidate > same < Pragma: no-cache > same < Expires: 0 > same < Strict-Transport-Security: max-age=31536000 ; includeSubDomains > same < X-Frame-Options: DENY > same < X-Application-Context: 0.3:8080 > < Cache-Control: no-store > < Pragma: no-cache > same < Content-Type: application/json;charset=UTF-8 > same < Connection: close > same < Set-Cookie: crbid=10.1.8.5:49387_mt05.prod.gini.net; path=/ > > regards > sabine > > 2015-02-27 16:58 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]>: > Sabine, > > > On 27 Feb 2015, at 16:36, Sabine Manaa <[hidden email]> wrote: > > > > Hi Sven, > > Hi all, > > > > I try to send a curl command (which works at command line) from Pharo. > > I get the error: "SSL Exception: decrypt failed code:5" > > > > The working command line command is: > > > > curl -v -H 'Accept: application/json' -u 'aUser:aPassword' > > 'https://user.xxx.net/oauth/token?grant_type=client_credentials' > > > > the result is something like: > > {"access_token":"a31xxxa-2a22-4xx6c-938d-2bd3ae4a0629","token_type":"bearer","expires_in":42095,"scope":"write"} > > > > My current Pharo code is: > > | theZnClient | > > theZnClient := ZnClient new > > systemPolicy ; > > https; > > host: 'user.xxx.net'; > > path: 'oauth/token?grant_type=client_credentials'; > > username: 'aUser' password: 'aPassword'; > > accept: ZnMimeType applicationJson; > > get. > > theZnClient inspect close. > > > > 'aPassword' and 'aUser' and xxx.net was replaced by me for security reasons. > > > > In Pharo, I get a walkback with the error message > > 'SSL Exception: decrypt failed [code:-5]' > > > > But I see, that the ZdcSecureSocketStream has the correct result > > ({"access_token":...":"write"}) in its collection attribute at > > utf-8 string and at latin1-string > > > > so, the request is done and the result is available but then it fails here: > > ZdcSecureSocketStream(Object)>>error: > > ZdcSecureSocketStream>>sslException:code: > > ZdcSecureSocketStream>>fillBytes:startingAt:count: in Block: [ ... > > ZdcSecureSocketStream>>fillBytes:startingAt:count: > > ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBufferNoWait > > ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer > > ZdcSecureSocketStream(ZdcOptimizedSocketStream)>>readInto:startingAt:count: > > ZnUTF8Encoder>>optimizedReadInto:startingAt:count:fromStream: > > ZnUTF8Encoder>>readInto:startingAt:count:fromStream: > > > > Sven, I could send you the 'aPassword' and 'aUser' and the url by private > > message. It would be fine if you could have a short look at it. > The fact that there is readable text in the buffer of the ZdcSecureSocketStream is good, because it means that things basically work. > > One reason why this is failing might be that Zn tries to read more than there is available in the stream, when the content-length does not match. Encoding problems could be part of the problem too. > > Could you compare curl -v or curl -D - output with the request/response headers in Pharo ? Look for content-length and compare that with what it already read or not. Is the connection kept alive ? Also look at content-type and see if there is any charset encoding after application/json. > > Sven > > > Regards > > Sabine > > > > > > > > -- > > View this message in context: http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808345.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808353.html > To start a new topic under Pharo Smalltalk Users, email [hidden email] > To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here. > NAML > > > View this message in context: Re: Zinc SSL Exception: decrypt failed code:5 > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. |
Re: Zinc SSL Exception: decrypt failed code:5
|
|
This sounds familiar to what we reported a while back:
Unfortunately, we did not investigate any further. Instead, we work around the bug by just retrying the connection on this failure as it always works on a second try. Johan
|
Re: Zinc SSL Exception: decrypt failed code:5
|
|
In reply to this post by Sven Van Caekenberghe-2
Hi Sven,
the error occurs on my Mac. Regards Sabine Am Freitag, 27. Februar 2015 schrieb Sven Van Caekenberghe :
|
Re: Zinc SSL Exception: decrypt failed code:5
|
|
In reply to this post by Sven Van Caekenberghe-2
I could send password etc to you for debugging of you want.
Am Freitag, 27. Februar 2015 schrieb Sven Van Caekenberghe-2 [via Smalltalk] :
|
Re: Zinc SSL Exception: decrypt failed code:5
|
|
In reply to this post by Johan Brichau-2
Hi Johan, I tried this: I put an exception handler around and on error, I tried again, but the error still occurs. Regards Sabine 2015-02-28 8:54 GMT+01:00 Johan Brichau-2 [via Smalltalk] <[hidden email]>: This sounds familiar to what we reported a while back: |
Re: Zinc SSL Exception: decrypt failed code:5
|
|
Hi Sabine,
I took a closer look and indeed, that strategy probably only works in our usecase where it’s a download of a zip tarball from github that fails in the Metacello code. Because on the second try, the github cache was already created, Metacello no longer sends the request to github and we pass by it. So, our ‘workaround’ does not apply outside of downloading from github. It does seem to be the same problem though. The SSL plugin is reporting an error while the connection closed just fine. If that’s the case, the culprit is the SSL plugin… Johan
|
Re: Zinc SSL Exception: decrypt failed code:5
|
|
We got a repeatable case:
https://pharo.fogbugz.com/f/cases/15022/ZdcSecureSocketStream-trouble-reading-response-with-no-content-length-and-connection-close ZnClient new get: 'https://user.gini.net/login' Now we just need a solution ;-) > On 28 Feb 2015, at 11:08, Johan Brichau <[hidden email]> wrote: > > Hi Sabine, > > I took a closer look and indeed, that strategy probably only works in our usecase where it’s a download of a zip tarball from github that fails in the Metacello code. > Because on the second try, the github cache was already created, Metacello no longer sends the request to github and we pass by it. > > So, our ‘workaround’ does not apply outside of downloading from github. > > It does seem to be the same problem though. The SSL plugin is reporting an error while the connection closed just fine. > If that’s the case, the culprit is the SSL plugin… > > Johan > >> On 28 Feb 2015, at 10:44, Sabine Manaa <[hidden email]> wrote: >> >> Hi Johan, >> >> I tried this: I put an exception handler around and on error, I tried again, but the error still occurs. >> >> Regards >> Sabine >> >> 2015-02-28 8:54 GMT+01:00 Johan Brichau-2 [via Smalltalk] <[hidden email]>: >> This sounds familiar to what we reported a while back: >> http://forum.world.st/Mac-sqDecryptSSL-returning-SQSSL-GENERIC-ERROR-on-errSSLClosedGraceful-from-SSLRead-td4785735.html >> >> Unfortunately, we did not investigate any further. Instead, we work around the bug by just retrying the connection on this failure as it always works on a second try. >> >> Johan >> >>> On 27 Feb 2015, at 23:36, Sven Van Caekenberghe <[hidden email]> wrote: >>> >>> >>>> On 27 Feb 2015, at 21:18, Sabine Manaa <[hidden email]> wrote: >>>> >>>> Hi Sven, >>>> >>>> thank you for your hints. >>>> >>>> Indeed, the variable @in of ZdcSecureSocketStream has the string "ZnInvalidUTF8: Illegal leading byte for utf-8 encoding" in its utf-8 variable. >>> >>> That is normal: the in buffer contains encrypted binary data, the out buffer will contain the cleartext (but still in binary). >>> >>>> Can you tell me, what to add to the pharo code that the encoding is correct/so that is equal to the curl command? >>> >>> I don't think there is an encoding problem: the charset is set to utf-8 which will be picked up. Besides, the returned content is plain ascii anyway. >>> >>> The issue is probably the Connection:close and the missing Content-Length. This means that the HTTPS stream has to be read until the end. I have seen this fail in the past in rare cases. >>> >>> Are you on Windows ? >>> >>> Could you try on Linux ? >>> >>>> comparison of headers: they seem to be equal, also the content type is in both cases 'application/json;charset=UTF-8' >>>> The ZnResponse headers: >>>> a ZnHeaders( >>>> same 'Cache-Control'->#('no-cache, no-store, max-age=0, must-revalidate' 'no-store') >>>> same 'Connection'->'close' >>>> same 'Content-Type'->'application/json;charset=UTF-8' >>>> same 'Date'->'Fri, 27 Feb 2015 20:02:40 GMT' >>>> same 'Expires'->'0' >>>> same 'Pragma'->#('no-cache' 'no-cache') >>>> same 'Set-Cookie'->'crbid=10.1.8.3:49247_mt03.prod.gini.net; path=/' >>>> same 'Strict-Transport-Security'->'max-age=31536000 ; includeSubDomains' >>>> same 'X-Application-Context'->'0.3:8080' >>>> same 'X-Content-Type-Options'->'nosniff' >>>> same 'X-Frame-Options'->'DENY' >>>> same 'X-Xss-Protection'->'1; mode=block' ) >>>> >>>> result of curl command at command line >>>> < HTTP/1.1 200 OK >>>> same < Date: Fri, 27 Feb 2015 17:58:37 GMT >>>> same < X-Content-Type-Options: nosniff >>>> same < X-XSS-Protection: 1; mode=block >>>> same < Cache-Control: no-cache, no-store, max-age=0, must-revalidate >>>> same < Pragma: no-cache >>>> same < Expires: 0 >>>> same < Strict-Transport-Security: max-age=31536000 ; includeSubDomains >>>> same < X-Frame-Options: DENY >>>> same < X-Application-Context: 0.3:8080 >>>> < Cache-Control: no-store >>>> < Pragma: no-cache >>>> same < Content-Type: application/json;charset=UTF-8 >>>> same < Connection: close >>>> same < Set-Cookie: crbid=10.1.8.5:49387_mt05.prod.gini.net; path=/ >>>> >>>> regards >>>> sabine >>>> >>>> 2015-02-27 16:58 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]>: >>>> Sabine, >>>> >>>>> On 27 Feb 2015, at 16:36, Sabine Manaa <[hidden email]> wrote: >>>>> >>>>> Hi Sven, >>>>> Hi all, >>>>> >>>>> I try to send a curl command (which works at command line) from Pharo. >>>>> I get the error: "SSL Exception: decrypt failed code:5" >>>>> >>>>> The working command line command is: >>>>> >>>>> curl -v -H 'Accept: application/json' -u 'aUser:aPassword' >>>>> 'https://user.xxx.net/oauth/token?grant_type=client_credentials' >>>>> >>>>> the result is something like: >>>>> {"access_token":"a31xxxa-2a22-4xx6c-938d-2bd3ae4a0629","token_type":"bearer","expires_in":42095,"scope":"write"} >>>>> >>>>> My current Pharo code is: >>>>> | theZnClient | >>>>> theZnClient := ZnClient new >>>>> systemPolicy ; >>>>> https; >>>>> host: 'user.xxx.net'; >>>>> path: 'oauth/token?grant_type=client_credentials'; >>>>> username: 'aUser' password: 'aPassword'; >>>>> accept: ZnMimeType applicationJson; >>>>> get. >>>>> theZnClient inspect close. >>>>> >>>>> 'aPassword' and 'aUser' and xxx.net was replaced by me for security reasons. >>>>> >>>>> In Pharo, I get a walkback with the error message >>>>> 'SSL Exception: decrypt failed [code:-5]' >>>>> >>>>> But I see, that the ZdcSecureSocketStream has the correct result >>>>> ({"access_token":...":"write"}) in its collection attribute at >>>>> utf-8 string and at latin1-string >>>>> >>>>> so, the request is done and the result is available but then it fails here: >>>>> ZdcSecureSocketStream(Object)>>error: >>>>> ZdcSecureSocketStream>>sslException:code: >>>>> ZdcSecureSocketStream>>fillBytes:startingAt:count: in Block: [ ... >>>>> ZdcSecureSocketStream>>fillBytes:startingAt:count: >>>>> ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBufferNoWait >>>>> ZdcSecureSocketStream(ZdcSimpleSocketStream)>>fillReadBuffer >>>>> ZdcSecureSocketStream(ZdcOptimizedSocketStream)>>readInto:startingAt:count: >>>>> ZnUTF8Encoder>>optimizedReadInto:startingAt:count:fromStream: >>>>> ZnUTF8Encoder>>readInto:startingAt:count:fromStream: >>>>> >>>>> Sven, I could send you the 'aPassword' and 'aUser' and the url by private >>>>> message. It would be fine if you could have a short look at it. >>>> The fact that there is readable text in the buffer of the ZdcSecureSocketStream is good, because it means that things basically work. >>>> >>>> One reason why this is failing might be that Zn tries to read more than there is available in the stream, when the content-length does not match. Encoding problems could be part of the problem too. >>>> >>>> Could you compare curl -v or curl -D - output with the request/response headers in Pharo ? Look for content-length and compare that with what it already read or not. Is the connection kept alive ? Also look at content-type and see if there is any charset encoding after application/json. >>>> >>>> Sven >>>> >>>>> Regards >>>>> Sabine >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808345.html >>>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>>>> >>>> >>>> >>>> >>>> >>>> If you reply to this email, your message will be added to the discussion below: >>>> http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808353.html >>>> To start a new topic under Pharo Smalltalk Users, email [hidden email] >>>> To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here. >>>> NAML >>>> >>>> >>>> View this message in context: Re: Zinc SSL Exception: decrypt failed code:5 >>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >>> >> >> >> >> If you reply to this email, your message will be added to the discussion below: >> http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808485.html >> To start a new topic under Pharo Smalltalk Users, email [hidden email] >> To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here. >> NAML >> >> >> View this message in context: Re: Zinc SSL Exception: decrypt failed code:5 >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > |
Re: Zinc SSL Exception: decrypt failed code:5
|
|
Hi,
I tried on Windows, there it works. Sabine |
Re: Zinc SSL Exception: decrypt failed code:5
|
|
Arg, and on Linux it works too.
Below the image layer, the normal Pharo code that we see, both the Socket plugin and the SSL plugin are three totally different implementations. This is really frustrating. The Mac code originates from *before* Mac OS X came on the scene ! Today, Mac OS X could probably use 99% of the Linux version. > On 01 Mar 2015, at 10:29, Sabine Manaa <[hidden email]> wrote: > > Hi, > > I tried on Windows, there it works. > > Sabine > > > > -- > View this message in context: http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808634.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. |
Re: Zinc SSL Exception: decrypt failed code:5
|
|
Excuse the silly question but what exactly is a plugin? Is it the code which is called by the primitive? The problem is not within the pharo code itself, right? It is the result of the primitive, which is wrong, right?
Can I do something more to solve the problem or should I try to write a workaround for me (exception handler and grab the result of the request)? Regards Sabine Am Sonntag, 1. März 2015 schrieb Sven Van Caekenberghe : Arg, and on Linux it works too. |
Re: Zinc SSL Exception: decrypt failed code:5
|
|
> On 01 Mar 2015, at 13:14, Sabine Manaa <[hidden email]> wrote: > > Excuse the silly question but what exactly is a plugin? Is it the code which is called by the primitive? The problem is not within the pharo code itself, right? It is the result of the primitive, which is wrong, right? Yes, we're talking about primitives. Plugins group primitives, some plugins are builtin, others are more like dynamic libraries, and live separate from the VM. The problem is that the C and OS implementations are different for each platform. Which can result in very subtle semantic differences. In this case it has something to do with detecting/handling a closed socket stream. > Can I do something more to solve the problem or should I try to write a workaround for me (exception handler and grab the result of the request)? From a user standpoint, no. We have a reproducible case now. Thanks for that. I am indeed afraid that you might need to think about a workaround, I can't promise anything about fixing this. Of course, anyone is free to help. Sven > Regards > Sabine > > > Am Sonntag, 1. März 2015 schrieb Sven Van Caekenberghe : > Arg, and on Linux it works too. > > Below the image layer, the normal Pharo code that we see, both the Socket plugin and the SSL plugin are three totally different implementations. This is really frustrating. The Mac code originates from *before* Mac OS X came on the scene ! Today, Mac OS X could probably use 99% of the Linux version. > > > On 01 Mar 2015, at 10:29, Sabine Manaa <[hidden email]> wrote: > > > > Hi, > > > > I tried on Windows, there it works. > > > > Sabine > > > > > > > > -- > > View this message in context: http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808634.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > |
Re: Zinc SSL Exception: decrypt failed code:5
|
|
Hi Sven, thanks for the explanation. If the problem would be in Smalltalk I could _try_ to find a solution but I am not able to go into primitives. Concerning my workaround: If remove the line where the exception is thrown in >>fillBytes:startingAt:count: "processedCount < 0 ifTrue: [ ^ self sslException: 'decrypt failed' code: processedCount ]." Then it works. So, it seems that ignoring the exception would fix the problem for me: [| theZnClient | theZnClient := ZnClient new systemPolicy ; https; host: 'user.gini.net'; path: 'oauth/token?grant_type=client_credentials'; username: 'spesenfuchs' password: 'asdf'; accept: ZnMimeType applicationJson; get. ] on: Error do: [ :ex | ex resume ]. But this needs that the exception is resumable. So could you perhaps make the exception resumable? ZdcSecureSocketStream>>sslException: text code: code self error: (String streamContents: [ :stream | stream << 'SSL Exception: ' << text << ' [code:'. stream print: code. stream << ']' ]) >>error: uses Error and this is not resumable. Could you make the Exception resumable? Then perhaps Johan could use resume, to? What is your opinion about this? Do I miss something here? Regards Sabine 2015-03-01 14:12 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]>:
|
Re: Zinc SSL Exception: decrypt failed code:5
|
|
Sabine,
Here is a possible fix that works for me, this still has to be tested more broadly, but I think it will be good. Could you please try it by manually loading the package ? === Name: Zodiac-Core-SvenVanCaekenberghe.36 Author: SvenVanCaekenberghe Time: 2 March 2015, 11:05:04.004975 am UUID: 3e14e0cf-fe1a-42b9-b093-b5b2c2be09bf Ancestors: Zodiac-Core-SvenVanCaekenberghe.35 Rewrite/refactoring of ZdcSecureSocketStream>>#fillBytes:startingAt:count: to fix an issue that occurred when reading a stream up to end. Note that some errors are now ignored the first time #decrypt:from:to:into: is called on left over data in the SSL session. Thanks Sabine Manaa for reporting this is issue. === Sven > On 01 Mar 2015, at 16:54, Sabine Manaa <[hidden email]> wrote: > > Hi Sven, > > thanks for the explanation. If the problem would be in Smalltalk I could _try_ to find a solution but I am not able to go into primitives. > > Concerning my workaround: > If remove the line where the exception is thrown in >>fillBytes:startingAt:count: > "processedCount < 0 ifTrue: [ ^ self sslException: 'decrypt failed' code: processedCount ]." > > Then it works. So, it seems that ignoring the exception would fix the problem for me: > > [| theZnClient | > theZnClient := ZnClient new > systemPolicy ; > https; > host: 'user.gini.net'; > path: 'oauth/token?grant_type=client_credentials'; > username: 'spesenfuchs' password: 'asdf'; > accept: ZnMimeType applicationJson; > get. ] on: Error > do: [ :ex | ex resume ]. > > But this needs that the exception is resumable. > > So could you perhaps make the exception resumable? > > ZdcSecureSocketStream>>sslException: text code: code > self error: > (String streamContents: [ :stream | > stream << 'SSL Exception: ' << text << ' [code:'. > stream print: code. > stream << ']' ]) > > >>error: uses Error and this is not resumable. > > Could you make the Exception resumable? > Then perhaps Johan could use resume, to? > > What is your opinion about this? Do I miss something here? > > Regards > Sabine > > > > > 2015-03-01 14:12 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]>: > > > On 01 Mar 2015, at 13:14, Sabine Manaa <[hidden email]> wrote: > > > > Excuse the silly question but what exactly is a plugin? Is it the code which is called by the primitive? The problem is not within the pharo code itself, right? It is the result of the primitive, which is wrong, right? > > Yes, we're talking about primitives. Plugins group primitives, some plugins are builtin, others are more like dynamic libraries, and live separate from the VM. > > The problem is that the C and OS implementations are different for each platform. Which can result in very subtle semantic differences. In this case it has something to do with detecting/handling a closed socket stream. > > > Can I do something more to solve the problem or should I try to write a workaround for me (exception handler and grab the result of the request)? > > From a user standpoint, no. We have a reproducible case now. Thanks for that. > > I am indeed afraid that you might need to think about a workaround, I can't promise anything about fixing this. Of course, anyone is free to help. > > Sven > > > Regards > > Sabine > > > > > > Am Sonntag, 1. März 2015 schrieb Sven Van Caekenberghe : > > Arg, and on Linux it works too. > > > > Below the image layer, the normal Pharo code that we see, both the Socket plugin and the SSL plugin are three totally different implementations. This is really frustrating. The Mac code originates from *before* Mac OS X came on the scene ! Today, Mac OS X could probably use 99% of the Linux version. > > > > > On 01 Mar 2015, at 10:29, Sabine Manaa <[hidden email]> wrote: > > > > > > > Hi, > > > > > > I tried on Windows, there it works. > > > > > > Sabine > > > > > > > > > > > > -- > > > View this message in context: http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808634.html > > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808670.html > To start a new topic under Pharo Smalltalk Users, email [hidden email] > To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here. > NAML > > > View this message in context: Re: Zinc SSL Exception: decrypt failed code:5 > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. |
Re: Zinc SSL Exception: decrypt failed code:5
|
|
Hi Sven, great - it works! Thank you very much for your help! Regards Sabine 2015-03-02 11:02 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]>: Sabine, |
Re: Zinc SSL Exception: decrypt failed code:5
|
|
> On 02 Mar 2015, at 12:46, Sabine Manaa <[hidden email]> wrote: > > Hi Sven, > > great - it works! Thank you very much for your help! You're welcome. BTW, a good bug report and a repeatible case makes all the difference. This is *very* important for us to make progress. > Regards > Sabine > > 2015-03-02 11:02 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]>: > Sabine, > > Here is a possible fix that works for me, this still has to be tested more broadly, but I think it will be good. Could you please try it by manually loading the package ? > > === > Name: Zodiac-Core-SvenVanCaekenberghe.36 > Author: SvenVanCaekenberghe > Time: 2 March 2015, 11:05:04.004975 am > UUID: 3e14e0cf-fe1a-42b9-b093-b5b2c2be09bf > Ancestors: Zodiac-Core-SvenVanCaekenberghe.35 > > Rewrite/refactoring of ZdcSecureSocketStream>>#fillBytes:startingAt:count: to fix an issue that occurred when reading a stream up to end. > > Note that some errors are now ignored the first time #decrypt:from:to:into: is called on left over data in the SSL session. > > Thanks Sabine Manaa for reporting this is issue. > === > > Sven > > > On 01 Mar 2015, at 16:54, Sabine Manaa <[hidden email]> wrote: > > > > Hi Sven, > > > > thanks for the explanation. If the problem would be in Smalltalk I could _try_ to find a solution but I am not able to go into primitives. > > > > Concerning my workaround: > > If remove the line where the exception is thrown in >>fillBytes:startingAt:count: > > "processedCount < 0 ifTrue: [ ^ self sslException: 'decrypt failed' code: processedCount ]." > > > > Then it works. So, it seems that ignoring the exception would fix the problem for me: > > > > [| theZnClient | > > theZnClient := ZnClient new > > systemPolicy ; > > https; > > host: 'user.gini.net'; > > path: 'oauth/token?grant_type=client_credentials'; > > username: 'spesenfuchs' password: 'asdf'; > > accept: ZnMimeType applicationJson; > > get. ] on: Error > > do: [ :ex | ex resume ]. > > > > But this needs that the exception is resumable. > > > > So could you perhaps make the exception resumable? > > > > ZdcSecureSocketStream>>sslException: text code: code > > self error: > > (String streamContents: [ :stream | > > stream << 'SSL Exception: ' << text << ' [code:'. > > stream print: code. > > stream << ']' ]) > > > > >>error: uses Error and this is not resumable. > > > > Could you make the Exception resumable? > > Then perhaps Johan could use resume, to? > > > > What is your opinion about this? Do I miss something here? > > > > Regards > > Sabine > > > > > > > > > > 2015-03-01 14:12 GMT+01:00 Sven Van Caekenberghe-2 [via Smalltalk] <[hidden email]>: > > > > > > On 01 Mar 2015, at 13:14, Sabine Manaa <[hidden email]> wrote: > > > > > > Excuse the silly question but what exactly is a plugin? Is it the code which is called by the primitive? The problem is not within the pharo code itself, right? It is the result of the primitive, which is wrong, right? > > > > Yes, we're talking about primitives. Plugins group primitives, some plugins are builtin, others are more like dynamic libraries, and live separate from the VM. > > > > The problem is that the C and OS implementations are different for each platform. Which can result in very subtle semantic differences. In this case it has something to do with detecting/handling a closed socket stream. > > > > > Can I do something more to solve the problem or should I try to write a workaround for me (exception handler and grab the result of the request)? > > > > From a user standpoint, no. We have a reproducible case now. Thanks for that. > > > > I am indeed afraid that you might need to think about a workaround, I can't promise anything about fixing this. Of course, anyone is free to help. > > > > Sven > > > > > Regards > > > Sabine > > > > > > > > > Am Sonntag, 1. März 2015 schrieb Sven Van Caekenberghe : > > > Arg, and on Linux it works too. > > > > > > Below the image layer, the normal Pharo code that we see, both the Socket plugin and the SSL plugin are three totally different implementations. This is really frustrating. The Mac code originates from *before* Mac OS X came on the scene ! Today, Mac OS X could probably use 99% of the Linux version. > > > > > > > On 01 Mar 2015, at 10:29, Sabine Manaa <[hidden email]> wrote: > > > > > > > > > > Hi, > > > > > > > > I tried on Windows, there it works. > > > > > > > > Sabine > > > > > > > > > > > > > > > > -- > > > > View this message in context: http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808634.html > > > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > > > > > > > > If you reply to this email, your message will be added to the discussion below: > > http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808670.html > > To start a new topic under Pharo Smalltalk Users, email [hidden email] > > To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here. > > NAML > > > > > > View this message in context: Re: Zinc SSL Exception: decrypt failed code:5 > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p4808807.html > To start a new topic under Pharo Smalltalk Users, email [hidden email] > To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here. > NAML > > > View this message in context: Re: Zinc SSL Exception: decrypt failed code:5 > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |