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.