On 22 February 2015 at 20:08, Sorvig Morten <[email protected]> wrote:
> > > On 22 Feb 2015, at 18:50, Jeremy Lainé <[email protected]> wrote: > > > > On 02/22/2015 06:42 PM, Richard Moore wrote: > >> > >> > >> On 22 February 2015 at 17:39, Jeremy Lainé <[email protected]> > wrote: > >> > >> Whilst I agree with the goal of dropping support for old / unmaintained > >> OpenSSL versions, in the case of OS X we probably need to map out the > >> transition in more detail - especially what policy to follow for the > >> official binary releases. My main concern is that in Qt 5.5 the > >> SecureTransport backend is available on OS X, but as far as I know we > >> are still aiming for OpenSSL-based binaries. This means that a lot of > >> users will not be exposed to this new backend at all, and then suddenly > >> in Qt 5.6 the old backend will be completely gone, with no way to build > >> it even from source. > >> > >> I think you're misunderstanding. Openssl will remain supported, just > not the outdated 0.9.8 branch apple ship. Users will still be able to make > use of openssl on mac they'll just have install a newer version. Does this > change your concerns? > >> > > > > I understood what you were saying, I think I just expressed my concerns > poorly. When I said "now way to build even from source", I meant "no way to > build support for OpenSSL as shipped by Apple". Anyway, my main concern is > : how do we encourage OS X users to make use of the new backend, to avoid > nasty surprises when it because the default backend? > > Ideally I'd like to ship both backends in the binary package, with a > runtime switch to select the active one, and make SecureTransport the > default. Users can then file bugs and ship their applications using the > OpenSSL backend if needed. > > This requires some changes to the 5.5 branch - both backends are named > "QSslSocketBackendPrivate". > Run-time switching isn't even something we've considered. I doubt it's feasible in the 5.5 time frame unless someone has quite a chunk of time to devote to it. It would require changes all over the place including the configure script. Might be a nice thing to have though. Cheers Rich.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
