- Pharo-users - lists.pharo.org

Re: [Pharo-users] SQLite3 - External module not found

by Julien Delplanque

First, thanks to take time to answer me. On 28/02/15 22:50, Bernardo Ezequiel Contreras wrote: > the symbolic link works in my pc. did you restart the image after > creating the link? or maybe the link is in the wrong place? Ok, I'll be a little more precise: The libsqlite3.so file is located in /usr/lib/ My pharo vm is located in ~/lib-perso/pharo3.0/ What I did is: ln -s /usr/lib/sqlite3.so ~/lib-perso/pharo3.0/bin/sqlite3.so Then I restarted the VM as you said but the error still appear when I tried the code I c/c in the first mail. Then I realized that /usr/lib/sqlite3.so is a symbolic link that point on /usr/lib/libsqlite3.so.0.8.6 so to be sure it wasn't just that, I tried the following commands: rm ~/lib-perso/pharo3.0/bin/sqlite3.so ln -s /usr/lib/libsqlite3.so.0.8.6 ~/lib-perso/pharo3.0/bin/sqlite3.so The error still appear, I'm really confused.

Feb. 28, 2015

Re: [Pharo-users] SQLite3 - External module not found

by Bernardo Ezequiel Contreras

the symbolic link works in my pc. did you restart the image after creating the link? or maybe the link is in the wrong place? On Sat, Feb 28, 2015 at 2:22 PM, Julien Delplanque <julien(a)tamere.eu> wrote: > Hello everyone, > > I have problems to get SQLite3 package working. I tried the solution > provided in another thread of the mailing list that was to create a > symbolic link from libsqlite3.so to a file located in the pharo3.0/bin > directory and named 'libsqlite3.so' as well but I still get the error: > External module not found. > > My OS is Archlinux (Linux version 3.18.6-1-ARCH (builduser@tobias) (gcc > version 4.9.2 20141224 (prerelease) (GCC) ) #1 SMP PREEMPT Sat Feb 7 > 08:44:05 CET 2015) and I'm using pharo3. > > The code that fail: > > c := SQLiteConnection fileNamed: ':memory:'. > c open. > > Maybe I'm missing something with the libsqlite3.so file? > > Thanks in advance, > > Julien > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Feb. 28, 2015

session four: a API with Zinc-REST on moose 5.1 (is: smalltalk workshops (building a webserver) after code-in)

by Martin BÃ¤hr

Excerpts from Martin BÃ¤hr's message of 2015-02-13 10:57:50 +0100: > > > you can read more about the workshop and find the screencast here: > > > http://societyserver.org/mbaehr/training/Using-the-FileSystem-class-in-Phar… > > part two is here: > > http://societyserver.org/mbaehr/training/Serving-files-through-FileSystem-i… > session 3 starts from scratch, using what was learned in the first two sessions. > http://societyserver.org/mbaehr/training/a-static-webapplication-hosted-on-… in session 4 we build a small RESTful API using the Zinc-REST package. http://societyserver.org/mbaehr/training/building-an-api-with-zinc-rest-in-… it was easier than expected to just copy from the Zinc-REST tests with small modifications. this screencast is going to be the contents of my workshop at FOSSASIA in singapore this month. since moose 5.0 worked quite well last time, except for being pharo 3, this time i am using the latest build of moose 5.1 which is using the latest pharo 4. greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

Feb. 28, 2015

Re: [Pharo-users] Zinc SSL Exception: decrypt failed code:5

by Sven Van Caekenberghe

We got a repeatable case: https://pharo.fogbugz.com/f/cases/15022/ZdcSecureSocketStream-trouble-readi… ZnClient new get: 'https://user.gini.net/login' Now we just need a solution ;-) > On 28 Feb 2015, at 11:08, Johan Brichau <johan(a)inceptive.be> 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 <manaa.sabine(a)gmail.com> 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-err… >> >> 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-tp4808230p48… >>>>> 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-tp4808230p48… >>>> 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-tp4808230p48… >> 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. >

Feb. 28, 2015

SQLite3 - External module not found

by Julien Delplanque

Hello everyone, I have problems to get SQLite3 package working. I tried the solution provided in another thread of the mailing list that was to create a symbolic link from libsqlite3.so to a file located in the pharo3.0/bin directory and named 'libsqlite3.so' as well but I still get the error: External module not found. My OS is Archlinux (Linux version 3.18.6-1-ARCH (builduser@tobias) (gcc version 4.9.2 20141224 (prerelease) (GCC) ) #1 SMP PREEMPT Sat Feb 7 08:44:05 CET 2015) and I'm using pharo3. The code that fail: c := SQLiteConnection fileNamed: ':memory:'. c open. Maybe I'm missing something with the libsqlite3.so file? Thanks in advance, Julien

Feb. 28, 2015

Zn using String>>#substrings:

by Sven Van Caekenberghe

Hi, Zinc HTTP Components' latest stable version 2.6.2 which was integrated in Pharo 4.0 is using String>>#substrings: instead of String>>#subStrings: For Pharo 4 this is of course OK. String>>#substrings: was also added to Pharo 3.0. For Pharo 2.0 Zinc will load a 'forward compatibility' package to add the missing method. If you are working in/with an older/existing Pharo 3.0 things will not be solved automatically. Either add the method yourself, or load 'Zinc-pharo2-forward-compatibility' manually. It might even be possible to update the image, but I haven't tried that. HTH, Sven

Feb. 28, 2015

Re: [Pharo-users] [ANN] Language Detection API Client

by Sebastian Sastre

nice one HernÃ¡n You are on fire lately! Thanks for sharing from mobile > On 28/02/2015, at 03:48, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > Hello, > > Language Detection API is a service to query the language of a given input text. You will need to register an API key in the web site http://detectlanguage.com to use the service. > > This client enables to use the service from Pharo Smalltalk. The output is an object containing the language code, a confidence score and a 'is reliable' boolean value. > > Installation and usage details in the following post: > > http://80738163270632.blogspot.com.ar/2015/02/languagedetection-api-client-… > > Cheers, > > HernÃ¡n > >

Feb. 28, 2015

Re: [Pharo-users] Zinc SSL Exception: decrypt failed code:5

by Johan Brichau

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 <manaa.sabine(a)gmail.com> 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] <x-msg://97/user/SendEmail.jtp?type=node&node=4808511&i=0>>: > This sounds familiar to what we reported a while back: > http://forum.world.st/Mac-sqDecryptSSL-returning-SQSSL-GENERIC-ERROR-on-err… <http://forum.world.st/Mac-sqDecryptSSL-returning-SQSSL-GENERIC-ERROR-on-err…> > > 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] <http://user/SendEmail.jtp?type=node&node=4808485&i=0>> wrote: >> >> >>> On 27 Feb 2015, at 21:18, Sabine Manaa <[hidden email] <http://user/SendEmail.jtp?type=node&node=4808485&i=1>> 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 <http://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 <http://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' <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 <http://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 <http://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-tp4808230p48… <http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48…> >>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com <http://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-tp4808230p48… <http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48…> >>> 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-tp4808230p48… <http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48…> > To start a new topic under Pharo Smalltalk Users, email [hidden email] <x-msg://97/user/SendEmail.jtp?type=node&node=4808511&i=1> > To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here <applewebdata://B04279EF-4F1C-4BF2-BDD8-32E5E1A31519>. > NAML <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > > View this message in context: Re: Zinc SSL Exception: decrypt failed code:5 <http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48…> > Sent from the Pharo Smalltalk Users mailing list archive <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com <http://nabble.com/>.

Feb. 28, 2015

Re: [Pharo-users] Zinc SSL Exception: decrypt failed code:5

by Sabine Manaa

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] < ml-node+s1294792n4808485h30(a)n4.nabble.com>: > This sounds familiar to what we reported a while back: > > http://forum.world.st/Mac-sqDecryptSSL-returning-SQSSL-GENERIC-ERROR-on-err… > > 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] > <http:///user/SendEmail.jtp?type=node&node=4808485&i=0>> wrote: > > > On 27 Feb 2015, at 21:18, Sabine Manaa <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=4808485&i=1>> 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-tp4808230p48… > 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-tp4808230p48… > 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-tp4808230p48… > To start a new topic under Pharo Smalltalk Users, email > ml-node+s1294792n1310670h65(a)n4.nabble.com > To unsubscribe from Zinc SSL Exception: decrypt failed code:5, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/Zinc-SSL-Exception-decrypt-failed-code-5-tp4808230p48… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 28, 2015

Re: [Pharo-users] Zinc SSL Exception: decrypt failed code:5

by Sabine Manaa

Hi Sven, the error occurs on my Mac. Regards Sabine Am Freitag, 27. Februar 2015 schrieb Sven Van Caekenberghe : > > > On 27 Feb 2015, at 21:18, Sabine Manaa <manaa.sabine(a)gmail.com > <javascript:;>> 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-tp4808230p48… > > > 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-tp4808230p48… > > 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. > > >

Feb. 28, 2015