On 2/3/11 11:46 AM, Henri Verbeet wrote:
> On 3 February 2011 18:58, Alexandre Julliard wrote:
>> It shouldn't have hacks, but I don't think it's unreasonable to use
>> platform-specific services for things that don't have widely accepted
>> standards.
>>
> That was mostly in reply to the general
Charles Davis wrote:
>
>On 2/3/11 9:22 AM, James Mckenzie wrote:
>> 2. Building ANYTHING Unix'y on a Mac may require 'hacky' patches to get
>> around some of the code issues. Both of the
>>known UNIX to MacOSX porting projects provide GnuTLS but have to patch it to
>>build and work on MacOSX w
On 3 February 2011 18:58, Alexandre Julliard wrote:
> Henri Verbeet writes:
>
>> On 3 February 2011 18:01, Charles Davis wrote:
>>> I'm for that. In fact, my humble opinion is that Wine on Mac should only
>>> use libraries that are part of the OS (i.e. only dylibs in /usr/lib and
>> I think Wine
Henri Verbeet writes:
> On 3 February 2011 18:01, Charles Davis wrote:
>> I'm for that. In fact, my humble opinion is that Wine on Mac should only
>> use libraries that are part of the OS (i.e. only dylibs in /usr/lib and
> I think Wine should have as few OS X (or Ubuntu for that matter)
> speci
> It sounds like things aren't nearly as murky as other licenses, but if
> we were in the position where we had to ship OpenSSL ourselves we
> might run into a problem.
We don't, we load it dynamically.
--Juan
On Mon, Jan 31, 2011 at 6:08 PM, Juan Lang wrote:
>> As Henri said, it's that it's a set of external dependencies (not just one;
>> GnuTLS has its own dependencies) and that they are security-related. To the
>> greatest extent practical, security-related libraries should come from one's
>> dis
On 3 February 2011 18:01, Charles Davis wrote:
> I'm for that. In fact, my humble opinion is that Wine on Mac should only
> use libraries that are part of the OS (i.e. only dylibs in /usr/lib and
I think Wine should have as few OS X (or Ubuntu for that matter)
specific hacks as possible.
On 2/3/11 9:22 AM, James Mckenzie wrote:
> 2. Building ANYTHING Unix'y on a Mac may require 'hacky' patches to get
> around some of the code issues. Both of the known UNIX to MacOSX porting
> projects provide GnuTLS but have to patch it to build and work on MacOSX
> without stepping on the exi
Juan Lang wrote:
I'll make this quick and address a comment here from Juan from the viewpoint of
someone building Wine from scratch using one of the porting services: Fink.
>
>Besides, I'm still not convinced that GnuTLS on the Mac is such an
>onerous problem.
This is not just a Codeweavers' pro
Hi Francois,
> As far as I understand it's not going to be another implementation. But
> you're probably right to warn about having multiple backends; that can
> be bad too as has been seen with sound.
Yes, that's part of my concern.
> Not true. Anyone using Wine on Mac OS X will benefit by not
On Tue, 1 Feb 2011, Juan Lang wrote:
[...]
> I may be flogging a dead horse here, but I personally am loath to see
> another implementation creep in, side by side with the existing one,
> that has no guarantee of working any better.
As far as I understand it's not going to be another implementatio
On Feb 2, 2011, at 11:38 AM, Juan Lang wrote:
> That's fine. You asked for feedback on your general approach, and
> described it as a proof of concept. I gave you feedback on it as
> such.
I appreciate your feedback. Although, in truth, I was asking more about how to
do it (wether to separate
Juan Lang writes:
> Since that thread, where I stated that new code based on OpenSSL
> wasn't likely to get accepted, an OpenSSL dependency was added to
> winhttp. Apparently I was mistaken.
It's not really new code, winhttp is just a copy of the wininet
code. The plan is still to get rid of Op
Hi Damjan,
> OpenSSL seems like a bad idea. It has poor binary compatibility and
> problematic FIPS 140 certification, and Fedora is dropping it in favour of
> NSS:
> http://fedoraproject.org/wiki/FedoraCryptoConsolidation
> http://fedoraproject.org/wiki/CryptoConsolidationEval
Maybe, but OpenSSL
>> I don't see how this
>> helps CodeWeavers, either, other than reducing installation
>> complexity.
>
> Well, Outlook didn't used to be able to connect to Gmail IMAP in our Mac
> product and now it does.
As I said, this only reduces installation complexity: I assume that,
had you installed Gnu
On Feb 1, 2011, at 10:19 AM, Juan Lang wrote:
> I may be flogging a dead horse here, but I personally am loath to see
> another implementation creep in, side by side with the existing one,
> that has no guarantee of working any better.
Well, it won't work any better, just as well as.
> I don't s
On 1 February 2011 17:19, Juan Lang wrote:
>> what IMO complicates writing them is that only the client part of
>> schannel is currently implemented.
>
> That might be true for writing tests against Wine's implementation,
> but there's nothing to stop them from being skipped if a server
> implemen
> Well, I think that regardless of what schannel ends up using, wininet
> and winhttp should be implemented on top schannel in the long term,
> instead of using OpenSSL directly. I don't think GnuTLS is really the
Well, that's certainly true, as there are features of at least wininet
that can't be
On 1 February 2011 02:08, Juan Lang wrote:
> Sure, I can buy that. I'll note that OpenSSL is also available for
> the Mac, and already loaded by wininet and winhttp. It could be
> appropriate to move from GnuTLS to OpenSSL for schannel, so we'd only
> have a single implementation for both Linux
On Tue, Feb 1, 2011 at 3:08 AM, Juan Lang wrote:
> Hi Ken, thanks for the reply.
>
> > As Henri said, it's that it's a set of external dependencies (not just
> one; GnuTLS has its own dependencies) and that they are security-related.
> To the greatest extent practical, security-related libraries
Hi Ken, thanks for the reply.
> As Henri said, it's that it's a set of external dependencies (not just one;
> GnuTLS has its own dependencies) and that they are security-related. To the
> greatest extent practical, security-related libraries should come from one's
> distro or OS vendor.
Sure,
Hi Juan,
On Jan 28, 2011, at 10:36 AM, Juan Lang wrote:
>> I'm planning to add an alternative implementation of schannel (SSL/TLS)
>> support for the Mac. The current implementation is based on GnuTLS. That
>> library is not typically found on Mac OS X. Although packagers can build it
>> an
On 28 January 2011 17:36, Juan Lang wrote:
> What's the issue with building GnuTLS? Is it that GnuTLS doesn't
> support the Mac Keychain? Is it that it's an external dependency? If
> the latter, we already pull in quite a bit that isn't found on the
> Mac, so the incremental change isn't large.
On 1/28/11 9:36 AM, Juan Lang wrote:
Hi Ken,
I'm planning to add an alternative implementation of schannel (SSL/TLS) support
for the Mac. The current implementation is based on GnuTLS. That library is
not typically found on Mac OS X. Although packagers can build it and ship it
and its dep
Hi Ken,
> I'm planning to add an alternative implementation of schannel (SSL/TLS)
> support for the Mac. The current implementation is based on GnuTLS. That
> library is not typically found on Mac OS X. Although packagers can build it
> and ship it and its dependencies with Wine for Mac OS X
25 matches
Mail list logo
