Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150102105722.GA18678@gremlin.ru>
Date: Fri, 2 Jan 2015 13:57:22 +0300
From: gremlin@...mlin.ru
To: owl-users@...ts.openwall.com
Subject: Re: Owl future

On 2014-12-30 06:32:13 +0300, Solar Designer wrote:

 > There are people who could contribute stuff, but if we opened
 > Owl up for contributions without close involvement from key
 > Owl developers, the resulting distro would make little sense
 > to me.

There could be different types of contributions, which require
different levels of involvement.

1. Misconfigurations and inconveniences. Generally these could
be solved by anyone, so they don't require the approval from
the very top - a brief discussion is enough.

2. Additional packages. Normally they are expected to be run
within the containers (in general, virtualization hosts should
not run anything except sshd for managing them and optional
msmtp for sending reports), so a brief check and keeping in sync
with upstream would be quite enough. That's how are built most
of packages published by me; I even have two packages with SUID
binaries (suexec from httpd and sudo), however they both are
04710 (accessible only for the special group).

3. Common packages. They are continiously maintained by our team
and may require some assistance from experienced members. However,
the maintenance itself should be delegated to others in order to
free our most valuable resources for

4. Critical packages (kernel, ssh, some libraries, shells). They
require "close involvement from key Owl developers", and we can't
avoid that.

Why I'm writing this? It's just a call for volunteers: whether
someone wish to participate in #1 and #2 (with a perspective of
getting into #3 or even #4), you are welcome to publish your
suggestions (in the `diff -burpN` format) here :-)

And yes, that's exactly how I've joined the team in 2001.

 > Let's look at this differently: what was the value of Owl so
 > far? I think it was primarily in trying out and demonstrating
 > to others some approaches, some of which have now been adopted
 > by other systems (and some changes went upstream).

For me, it was a primary platform for almost all of my projects,
and since it got the OpenVZ support, it is the only platform for
all my projects.

Of course there are some features that require me to rebuild it
from scratch to match my needs, but I do that only 2...3 times
per year, compared to 20...30 installations.

 > I think the positive impact of this can be greater. Maybe some
 > of us could actively contribute to other distros e.g. to make
 > them SUID-less?

Once they will need that, I guess they will adopt our developments.

 > For example, I think Alpine Linux may be a good distro to
 > contribute to.

Very unlikely... They sacrifice compatibility in favor of size
(primarily) and security (obvious side effect for a minimalistic
system).

 > Surely there are others. Maybe also some *BSDs.

They are out-of-scope from the business PoV.

 > As to contributing to mainstream distros, I don't mind, but
 > frankly I don't feel our userland security hardening enhancements
 > are of as much value when mixed with a lot of other stuff in a
 > distro like Fedora or Ubuntu.

We simply don't need all that stuff. Instead, we need some other
stuff - like nginx, rsync and qemu (which I already maintain for
my customers), or PXE support (including installation media).

 > Having our approaches adopted by multiple distros also side-steps
 > the issue of systemd. The distros may vary in this aspect.

You've mentioned the Alpine Linux several lines above... could you
imagine them swithing to systemd? I can't :-)

 > Finally, as to the future of Owl itself, we need to know why
 > we'd be continuing to put effort into Owl. Do we have more
 > new approaches to demo to others in this way, or would we be
 > playing catch-up? I think it might be mostly the latter.

We have some old approaches to show others what they've lost (or
never had), like keeping the system quite small while including
out-of-box support for virtualization. Even my attempt to rewrite
the owl-startup (which started this thread) was primarily destined
to support some complex datacenter environments.

 > There are things other hardened distros did and we didn't do
 > yet, so we can merge those in and create a distro that is in
 > some ways better overall. (In fact, this was the plan a couple
 > of years ago, but we didn't proceed to execute on it much yet.)

I could miss something, but there shouldn't be really much to do.

 > Is demo'ing this combination worth the effort?

Unlikely.

 > Would it inspire others to do anything better?

Unpredictable.

 > Is it worth the effort merely for actual use of it during the
 > period that we'd be maintaining it and keeping it up-to-date?

Hopefully it will, as it did before and does now.

 > I think Owl is, and will be (until EOL'ed), one of Openwall's
 > several projects (not "the main project"). There are other
 > things I'd like to work on (as well or instead). So if Owl is
 > primarily for its actual use while it's maintained, rather than
 > for indirect positive impact on other projects

The second is impossible without the first.

 > I will want to limit my time spent on Owl and to spend more of
 > my time on our other projects instead (including some future
 > ones). I've been doing just that lately.

So you may want to delegate some of your duties to other members,
stepping in only when really necessary.

P.S.: Happy New Year!

-- 
Alexey V. Vissarionov aka Gremlin from Kremlin <gremlin ПРИ gremlin ТЧК ru>
GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 @ hkp://keys.gnupg.net

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.