[WBEL-devel] Long- Thoughts on WB maintenance (was Re: How to get the RHEL Errata?)

[Vlad Mazek]

Not to be overly pessimistic here, but from their track record, RedHat is
probably going to be happiest if there is 0 mention of RedHat, RedHat Linux
or any other trademark that can even imply this project having any
relationship/similarity/trace to RHLE. As long as WBEL stays out of RedHat's
way I'm sure the opposite will be the case as well. 

I like the idea of a patch w/ SRPM but that doesn't solve the problem of
embedded images containing their trademarks. So long as WBEL is only
distributing a patch/shell script it would save an immense amount of
bandwidth and would leave the end user with the fair "at-your-own-risk"
caveat. 

-Vlad

-----Original Message-----
From: whitebox-devel-admin@beau.org [mailto:whitebox-devel-admin@beau.org]
On Behalf Of Sebastian Welsh
Sent: Wednesday, November 26, 2003 8:10 PM
To: Vlad Mazek
Cc: whitebox-devel@beau.org
Subject: [WBEL-devel] Long- Thoughts on WB maintenance (was Re: How to get
the RHEL Errata?)

On Thu, 2003-11-27 at 04:09, Vlad Mazek wrote:
> Either a mailing list or a web page that indicates the package name 
> and the severity of the problem. Here is the problem that might come 
> up: 1) package xyz has a remote root exploit 2) a day later RedHat 
> comes out with a patch
> 3) x amount of time for WBEL to strip out the copyrights, rebuild the 
> package, etc.
> 
> -Vlad

As the bulk of material requiring removal is static, I anticipate that most
often, patches to sanitise new releases will be identical to preceding
package releases/errata. 

Unless RedHat substantially change the shape of a package in an errata
release (unlikely IMHO), I believe we'll be able to push updates in an
acceptable release window.

This raises a couple of interesting points to consider:
- how we can foster a warm relationship with RedHat. 
- how we can ensure timely release of errata

I believe that the first may assist with the second. Here is a straw man to
work on:

Relationship with Redhat
========================
We need RedHats goodwill, as the viability of WhiteBox depends on the ease
of migration of upstream packages. If RedHat substantially modify packages
between errata releases, we have a whole lot of work to maintain WB. There
is also have no guarantee that we can release errata in a timely fashion if
we have to rework each package from scratch. So, it seems to me that we
should ask the question- what can we offer RedHat to maintain a good
relationship?

My first thought is that WhiteBox can be viewed as a gateway distribution to
the RedHat Enterprise range. An entity using WhiteBox should be encouraged
to use RedHat if they can afford it. We should highlight the differences
which I see as: 
 - the support structures provided by RedHat
 - the best-effort(WB) versus purchased-facility(RH) products
 - release timing of errata
and point out the benefits of this for an organisation. Another term for
this might be "product endorsement".

We may want to emphasise this on the website, in the install instructions,
in the installer splash documentation, with a free temporary tattoo etc.

As an individual I loathe the intrusion of advertising and product
marketing. However, it seems to me that we are, in effect, riding on the
shoulders of giants and it would be poor manners to leave the impression
that we are ungrateful.

Other people have suggested that WB provides a product proofing facililty
for RedHat. If WB ensures that
 - bug reports generated from WB installs reach WB, rather than RH
 - WB aggregates bug reporting and provides input to RH only after
confirming the bug exists in RHEL I expect with this approach we are less
likely to generate grumbles from the RH support structure, and WB may be
viewed as a benefit rather than an imposition.

Finally, I believe WB can offer RedHat a similar advantage in the server
environment that Fedora offers in less stable environments: it maintains an
install base of RH compatible products, which means their commercial
offering isn't sidelined.

Errata maintenance
==================
Another straw man here:

First, WB places trust in the integrity of RH supplied SRPMs. A user who
wishes to validate a WB supplied package should be able to easily compare it
against a RH supplied package. Therefore, the WB maintenance model should
not only be easy and compatible with RHEL, it should be easily reverible,
and easily identifiable. 

Modifications to the package contents are applied in 2 ways:
 - modification of the SRPM spec to remove violating dependencies. These
changes are flagged in the SRPM. 
 - insertion of a WB patch to the SRPM spec applied at the end of the patch
list - in other words, the patch unpatches the RedHat patches
(phew!)

It seems to me that this approach makes it easy for an end user to check the
validity of a WB SRPM against a RH SRPM by easily removing the WB
modifications. It also make it easy for an end user to examine the changes
made by WB if they wish.

I believe that this approach is well suited to the good ol package
maintainer model. However, it still leaves us in a bit of a bind as our
updates will still lag behind those of RedHat, and as a single maintainer
has to do things like eat, sleep, holiday and walk dogs, we need an override
mechanism to push out errata independent of maintainer availability.

Part of that comes from my earlier discussion about good relationships with
RedHat. If we have good channels of communication we may be able to prepare
for errata release with soem forewarning. However, I don't expect RedHat
would be willing to provide errata ahead of public release, as to do so
would erode some of the business case for RHEL. I'd be happy to find out I
am wrong.

Another part of the override mechanism may be to run a maintainer group for
each package, especially big, ugly packages. This may help when substantial
work is required to sanitise a package.

The final mechanism I can think of is to run a security group that uses
and/or updates the existing patch to run out errata where the maintainer is
unable to do so in a timely fashion. This approach is really only feasible
when the errata package has not changed substantially.

I can see one gotcha with this approach. I'm assuming here that we know
ahead of time what packages require cleaning. If a previously unencumbered
package is released where the new release is encumbered, we would have a mad
scramble to release an update- assuming we identified it! Any ideas?

Hope that this is food for thought.

Seb


_______________________________________________
Whitebox-devel mailing list
Whitebox-devel@beau.org
http://beau.org/mailman/listinfo/whitebox-devel