Re: [OmniOS-discuss] OpenSSL futures

[Lauri Tirkkonen]

On Mon, Apr 04 2016 22:15:12 +0100, Peter Tribble wrote:
> On Thu, Mar 31, 2016 at 3:40 PM, Dan McDonald  wrote:
> > I'm starting this thread to hear what the community has to say about where
> > OmniOS should go w.r.t. its OpenSSL release.  I have internal customers
> > too, of course, but I'll engage them separately.  We need to have an
> > OpenSSL because illumos requires one.  We *could* do the SmartOS thing and
> > keep our own SUNW/OMNI*...() api set, though.
> >
> 
> They have to play those games because they ship 2 different openssl
> instances,
> though. (One with the platform, one via pkgsrc or whatever.) If you hide
> the internal
> copy, you still have to manage (or someone does, at any rate) compatibility
> and
> releases of the public copy. The problem doesn't go away, you just sweep it
> under
> someone else's carpet.

Here's another viewpoint though: I would like to choose the SSL
implementation used in my application stack, so I want this problem
under my carpet. Not just because I believe it has security benefits
(eg. getting ssl2 *actually* disabled; it couldn't be disabled in the
OmniOS shipped OpenSSL because that broke binary compatibility), but
also because my SSL library of choice ships a sane API (libtls [0]). If
OmniOS keeps shipping OpenSSL as a mandatory component *without*
changing its symbol names, I can't do what I want in my application
stack.

> Users will have binaries linked against the existing openssl libraries, and
> those
> need to continue to run.

OmniOS has removed (ie. stopped shipping) some other libraries in the
past [1], but I understand the OpenSSL story might be a little
different. Perhaps there's a middle ground here though: it seems like
you and I would both be happy if OmniOS kept shipping OpenSSL, but made
it optional (although then obviously it would have to have another copy
with mangled symbol names for the things illumos needs it for).

[0]: http://man.openbsd.org/OpenBSD-current/man3/tls_accept_fds.3
[1]: eg. 151006 removed several libraries, including libgnutls and
libgcrypt. http://omnios.omniti.com/wiki.php/ReleaseNotes/r151006

-- 
Lauri Tirkkonen | lotheac @ IRCnet
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OpenSSL futures

[Peter Tribble]

On Thu, Mar 31, 2016 at 3:40 PM, Dan McDonald  wrote:

> As I'm updating and checking packages for r151018's release, I notice that
> OpenSSL is rapidly approaching a 1.1.0 release.  I visited their Release
> Strategy page:
>
> http://openssl.org/policies/releasestrat.html
>
> And noticed that 1.0.2 is LTS until 2019.  OTOH, 1.1.x will likely become
> LTS for some x,


For x > 0 and as yet unannounced. Although the policy tells us roughly when
the next LTS is announced, end 2018 would seem reasonable.

What this tells me is to stick to 1.0.2 as the supported branch until the
next LTS
is decided. I'm presuming everything is going to be properly versioned so
that
one can ship two versions of the shared library in parallel for a
transitional period.

(Hm. Sounds rather like the libpng story in terms of evolving the API by
making
structures opaque. Although libpng changes the library name as well as the
version number of the .so. But my experience there was that the transition
was pretty ugly.)


> and there's also LibreSSL...
>

Not to mention PolarSSL and WolfSSL and ...

None of which are binary compatible with the current openssl (by which I
mean
you can use them as shared-library replacements). Although recent events
have
shown that openssl releases aren't quite as binary compatible as one would
like.


> I'm starting this thread to hear what the community has to say about where
> OmniOS should go w.r.t. its OpenSSL release.  I have internal customers
> too, of course, but I'll engage them separately.  We need to have an
> OpenSSL because illumos requires one.  We *could* do the SmartOS thing and
> keep our own SUNW/OMNI*...() api set, though.
>

They have to play those games because they ship 2 different openssl
instances,
though. (One with the platform, one via pkgsrc or whatever.) If you hide
the internal
copy, you still have to manage (or someone does, at any rate) compatibility
and
releases of the public copy. The problem doesn't go away, you just sweep it
under
someone else's carpet.

Users will have binaries linked against the existing openssl libraries, and
those
need to continue to run.


> I can't guarantee what I'll ultimately decide, but knowing what people
> think can't hurt.
>

Thanks for asking!

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

[OmniOS-discuss] OpenSSL futures

[Dan McDonald]

As I'm updating and checking packages for r151018's release, I notice that 
OpenSSL is rapidly approaching a 1.1.0 release.  I visited their Release 
Strategy page:

http://openssl.org/policies/releasestrat.html

And noticed that 1.0.2 is LTS until 2019.  OTOH, 1.1.x will likely become LTS 
for some x, and there's also LibreSSL...

I'm starting this thread to hear what the community has to say about where 
OmniOS should go w.r.t. its OpenSSL release.  I have internal customers too, of 
course, but I'll engage them separately.  We need to have an OpenSSL because 
illumos requires one.  We *could* do the SmartOS thing and keep our own 
SUNW/OMNI*...() api set, though.

I can't guarantee what I'll ultimately decide, but knowing what people think 
can't hurt.

Thanks,
Dan

___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OpenSSL futures

[Bob Friesenhahn]

On Thu, 31 Mar 2016, Dan McDonald wrote:


I'm starting this thread to hear what the community has to say about 
where OmniOS should go w.r.t. its OpenSSL release.  I have internal 
customers too, of course, but I'll engage them separately.  We need 
to have an OpenSSL because illumos requires one.  We *could* do the 
SmartOS thing and keep our own SUNW/OMNI*...() api set, though.


Currently many OmniOS users are building their own applications using 
the OpenSSL that comes with OmniOS.  If OmniOS removes the OpenSSL 
version that these applications were using, then the applications will 
fail to run.  While it is useful to offer the current OpenSSL release 
branch (OmniOS provides "fresh" software), there needs to be a way to 
bridge so that OmniOS users are not struck with severely broken 
servers (requiring that all packages depending on OpenSSL be rebuilt) 
due to stepping to the next OmniOS release.


With sufficient advance notice we can build our own OpenSSL and 
rebuild all of our packages to use our own OpenSSL and update 
application configurations (e.g certificates) so that they still work. 
By doing so we lose the security-fix support that OmniOS has been 
providing and need to take this reposibility for ourselves.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] OpenSSL futures

[Bob Friesenhahn]

On Thu, 31 Mar 2016, Lauri Tirkkonen wrote:


I would personally like to see LibreSSL either in OmniOS itself or the
possibility to use it in my own application stack (eg. the SmartOS route
of changing the symbol names of the OS-shipped TLS library to avoid
conflicts).


While the notion of LibreSSL is great, we should take care because 
LibreSSL is targeted to OpenBSD APIs and requirements.  Some behaviors 
have subtle (yet significant) differences and the differences need to 
be carefully considered to make sure that behavior is correct under 
Illumos.  For Linux there are known cases where the OS difference 
resulted in a security weakness (which may still exist).


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss