[Bug 30931] Newsbin cannot connect to ssl servers

wine-bugs at winehq.org wine-bugs at winehq.org
Sun Jun 17 18:08:07 CDT 2012


http://bugs.winehq.org/show_bug.cgi?id=30931

--- Comment #10 from Juan Lang <juan.lang at gmail.com> 2012-06-17 18:08:07 CDT ---
(In reply to comment #9)
> 1 - If by threading change, you mean the fact that Newsbin has to supply a
> bunch of mutexes to OpenSSL (which did bite me on the ass). It's already
> implementing that change internally.   OpenSSL calls up and I then generate the
> N mutexes it requests


I was going on memory, and my memory is fallible.  The changes referenced in
bug 30598 are related to TLS version negotation.  Like you say, if this works
on Windows, I don't see why it would impact the app on Wine.  What I was
referring to was another relatively recent change in openssl that produced a
crash in another app that seemed related to threading.  That's described in bug
30246.  However, bug 30246 mentions that it works up to version 1.0.0.g, and
your app is linked to 1.0.0.d, hence neither bug seems related to me.  Sorry
for the confusion.

> 2 - 
> >>OK Fix 
> >>Use this 
> >>echo 0|sudo tee /proc/sys/kernel/yama/ptrace_scope
> 
> The fix that makes it work is completely unrelated to SSL version.  I think the
> real question is, how does enabling ptrace security interfere with OpenSSL
> under wine. Is wine using ptrace to patch the application in memory or monitor
> what it's doing? Is it used to implement SEH (structured exception handling)
> for instance?  
> 
> In a nutshell, disabling ptrace security allows OpenSSL to work. That suggests
> that ptrace is being used to do something. I don't know anything about wine
> internals so I can't guess what.  Why only SSL too? Why do normal TCP
> connections work but, SSL connections don't?

Yes, Wine does use ptrace to support certain Windows APIs, e.g.
GetThreadContext and ReadProcessMemory.  How it's related in this context is
hard to guess.  Some SSL connections do work, so it's not as simple as "TCP
works, SSL doesn't."

A starting point might be looking at a +relay log, to see what the app was last
doing prior to its point of failure.  Or, since you have the source of the app,
if you have a tracing mechanism within it, or can instrument it with some, that
might be more efficient.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the wine-bugs mailing list