Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 27 Jun 2015 16:59:47 +0300
Subject: Re: OpenSSL

On 2015-06-11 21:54:39 +0300, Solar Designer wrote:

 > It looks like our options are:

Only one:

 > 4. Ignore Red Hat's patches, just package upstream OpenSSL's
 > code with our patches.

We may use RH patches, but aren't required to.

 > Drawback: then we're not justified to keep Red Hat's soname,
 > so we break binary compatibility with RHEL.

Actually, we've lost it several years ago when we stuck with old
glibc-2.3 - so we can safely drop this compatibility notice.

>From my experience (2 all: in 5 recent years, I was primarily
working as a system architect for HA+HL systems), when people
need RHEL compatibility, they take CentOS and nothing else.

 > 6. Give up on Owl.

Not an option at all.

 > I feel that deciding on this should be part of a bigger
 > decision on where Owl is heading.

I see at least one not-yet-filled area: virtualization host for
both VPSes (OpenVZ) and VDSes (KVM).

Also it's really good as a base for guest system templates for
some common services like mail servers (I use dovecot and exim
running in one container), web servers (separate containers for
nginx frontend and various backends), database servers (I use
either MongoDB, MySQL or PosgreSQL), VPN servers (OpenVPN in a
KVM-based VDS), etc.

And yes - I've tried other solutions, but they are either ugly
or expensive.

 > Should it still maintain any RHEL compatibility?

No. There's none in recent years, and that never was a problem.

 > If not, then is there sufficient reason for us to use RPM


 > and to continue building Owl as a Linux distro?

Yes. There really is a strong requirement for a small and secure,
but also functional system.

The main problem with Owl is the lack of out-of-box usability.
Well, 10 years ago it had some sort of, but now it can perform
only two functions: VPS host (without live migration support)
and DNS server (requires manual configuring other than simply
adding zones).

 > I mean, there's lots of crap not only in OpenSSL and RHEL,
 > but also in RPM

Alas, all other options are much worse.

 > and in the Linux kernel, but we chose those for compatibility.
 > So if we start to drop compatibility, then how far do we go?

80% of compatibility may achieved with only 20% effort.

 > And does our project still make sense then?

Obviously, yes.

 > Previously, we'd choose option 2 from the list above, but at
 > this time I'm not sure. I'd like to minimize the effort spent
 > on maintenance, and to direct more effort to doing new and
 > longer term beneficial things.

Now our choice could be only #4.

Alexey V. Vissarionov aka Gremlin from Kremlin <gremlin  gremlin  ru>
GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 @ hkp://

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ