Owl River Company

Your IP is: 54.234.126.92

Independent RPM packaging project, and Owl River SRPMs, and tracking system meta-information project

First, there was 'contrib.redhat.com' -- but it was too hard for an end consumer to know the quality of the packagings, and for the packager to address updated releases and security matters.

Then there was the Matthias Saou's freshrpms.net and Bero (Bernhard Rosenkraenzer)'s archive. Bero has moved to new digs with "Ark Linux" and each have a fine product.

The Owl River archive has had the bits and pieces which leak, unsigned, from our commercial packaging for clients.

In late 2002, Warren Togami proposed and worked on a public 'community based' independent RPM packager's infrastructure -- a 'Fedora project'. Several of the independent packagers were drawn to it. But, as of the end of April 2003, methodology items had still not been ironed out. See: Fedora website Eventually, with Red Hat discontinuing its supported 'Red Hat Linux' product, and exiting the boxed consumer product market, Togami announced a 'merger' of the formerly non-affiliated Fedora.US project into Red Hat control. He also took a position with them around that time.

In support of the Fedora project, we participated in process, and published several 'thought piece' items. Formal and systematic pieces for comment, not enumerated or linked at the Fedora project website include the following:

Commentary on the initial Fedora proposal - (mailing list copy)
A proposed build flow and QA document for comment (revised) - (mailing list copy - initial post) - See also: ftp://ftp.owlriver.com/pub/local/ORC/packaging for ORC_flow_build which is a build wrapper script, designed to catch the relevant build environment variables and details, in a fashion adequate for a remote 'QA reviewer' to reproduce and diagnose non-conformances and build environment issues by a 'Packager'.
Response to Update - (mailing list copy)
Response to 'Overlaps' - Fedora Package Wish List - (mailing list copy)
rhel-rebuild build systems outline

'A Scout is trustworthy, ...'

audio quid ueteres olim moneatis amici,
"pone seram, cohibe." sed quis custodiet ipsos
custodes? cauta est et ab illis incipit uxor.

I hear always the admonishment of my friends:
"Bolt her in, constrain her!" But who will guard
the guardians? The wife plans ahead and begins with them!

-- Juvenal's Satire 6, p. 346â€“348, vice Wikipedia

Great care is needed, as defenders of complex systems, by definition can only play defense; an attacker only has to score 'once':

Ken Thompson's Trusting Trust piece - August 1984, responding to: "How the Air Force cracked Multics Security"
D Wheeler response - still an open issue, thirty years later; proposed for Fedora and shot down
GnuPG -- A few minutes on using detached and clearsigned content -- How can we know the person who asserts a thing, actually did say it?

... introspection

We compile some compromises in FOSS space, as it does no good to avert one's eyes; how one responds is important, as 'security is a process of risk control.'

2000 Sun Certificates (2) compromise
2002 sendmail compromise
2002 OpenSSH compromise - advisory
2003 Linux kernel CVS repository direct alteration, leapfrog-ed in from a hacked box at a university
2003 Gentoo rsync mirror compromise -- remote exploit via rsync; post mortem
2003 Signature checking need - Unhappily - GNU archive (local .pdf); (prime)
2003 Signature checking need - Unhappily - Debian CVS (local .pdf) (prime)
2004 Gnome.org (Red Hat's and others' response to the then non-Free qt)
2004 and later Several Google compiled
2007 Ubuntu compromise
2008 Red Hat trap-doored code presented and signed
2008 Fedora signing server compromised
2008 World Bank interior network compromised - || archive items: Fox story (PDF), Bank internal website screenshot (PDF)

Sensibly, such care is driven in part by having defined process, duly critiqued, and spot tested. Some complain that too much process gets in the way of production, but the counter-comment echoes that familiar precept that 'Security is a Platonic ideal: to be strived for, but not an absolute which can be attained.'

We remain interested in several areas, and have re-focused back to our primary interest in clean RPM packaging and automated builds. We have found a good fit in the Community Au-courant Operating System - http://www.caosity.org/, led by Greg Kurtzer, in line with having a target for our efforts. We also are involved with Yellow Dog Linux, and the Sparc Aurora project to the same effect.

We hope to be able to take virgin sources, provable signatures, .spec files, hint files, rpm, yum, a buildfarm, and an ftp server, and ultimately spit out nightly make world test .ISO images, for loopback mounting, and PXE based network installs, updates, and upgrades.

Reproducible builds

Quality assurance both for internal development processes, and for assurance to external audiences, require the ability to know all of the relevant elements which made up a given package. In our Wingstm distribution, we seek to start from a small, competent nucleus installation, and to then surround it with a well defined, tested configuration; and to maintain it with a series of known and defined patchsets.

We started with the decomposed intermediate goal of automating the SRPM build time build-dependency satisfaction process in a thought piece about reproduceable and repeatable fashion, and trans-architecture build compatibility verification. The piece also touched on the wider topic of automated production practices, which attracted some comment, but not as much as we had hoped for.

Recipes for builds

We have also been interested in rationalization of RPM .spec file (the XML hooks will help as they get application tools built out), and worked with some other RPM developers, to get these 'hooks' in place for permitting automated 'draft' recipe generation.

Cookbooks for builds

The traditional (and largely shifting sands) of the Red Hat 'anaconda' installation tool, and its 'hooks' for doing automated installs and upgrade time dependency solving, are old reliables, which we have documented elsewhere.
But see also: yum for the most interesting new approach we have seen recently. Yum is an enabling approach in the technology, permitting effective and easy central change control compliant configuration and maintenance, and also permitting automation of the SRPM build time build-dependency satisfaction process in a reproduceable and repeatable fashion, and trans-architecture build compatibility verification and automated production practices.

To these ends, we will continue to publish this page and act as a clearinghouse for certain meta-archive information.

Right now, the best existing approach in RPM-based Linux distributions seems to be the informal network of independently packaged freely-available archive of SRPMS -- Source RPM's -- which should contain all needed parts for clean build. Most of the distribution packaging houses are packaging GPL'd or other OSI license compliant code, with a concomitant source code release (including patches) requirement (GPL) or convenience (BSD-ish licenses). If the distribution or packager is based on the RPM packaging system, it is easier to release the SRPM than to decompose it into parts, and solve namespace conflict issues. And so, SRPMs are the most common delivery mechanism for source code.

(Please note that we do not minimize the BSD tarball 'ports' and 'make world' system; nor 'pkgtool', '.deb', depot, or related systems -- they are just not the most interesting branch for facility in automated rebuilding. Usually five minutes with a tarball and a template file, and a skilled .spec-file packager can have a 'rough draft' SRPM in process.)

If a given SRPM does not build cleanly, there is a bug which needs to be reported, at least to the distribution packager, if not the upstream developer or maintainer of the underlying code. Building a community infrastructure to ensure patching is not lost, and when security is an issue, that an alternative patch, pending an 'official' main-line fix is also part of the dull stuff which will improve the Open Source breed.

We have recently found: ~~#rpmbuild~~ renamed to #packaging on irc.freenode.net and hang out there. Primarily, however, we are at: #centos in that facility.

Major independent packagers we watch or are aware of (alphabetical order by last name)
Ronny Buchmann	Vlugnet	http://vlugnet.org/
Rex Dieter	rdieter math.unl.edu	http://www.math.unl.edu/~rdieter/Projects/ -- Also KDE for Red Hat http://kde-redhat.sourceforge.net/
Matthew Hall		http://people.ecsc.co.uk/~matt/repository.html
Rudolf (Che) Kastl	che666 uni.de	http://newrpms.sunsite.dk
Fernando Lopez-Lezcano	PlanetCCRMA	http://www-ccrma.stanford.edu/planetccrma/software/
Panu Matilainen	pmatilai welho.com	http://koti.welho.com/pmatilai/misc/
Dams Nade (anvil)	rpm.livna.org	http://rpm.livna.org/
David NeÄas (Yeti)	yeti physics.muni.cz	http://trific.ath.cx/resources/rpm/
Matthias Saou	matthias rpmforge.net	http://freshrpms.net
Ville Skyttä	ville.skytta iki.fi	~~http://cachalot.ods.org~~ http://cachalot.mine.nu/1/
Ralf Spenneberg		http://www.spenneberg.com/index.php
Thomas Vander Stichele	thomas urgent.rug.ac.be	http://thomas.apestaart.org/projects/
Axel Thimm	Axel.Thimm physik.fu-berlin.de	http://atrpms.physik.fu-berlin.de/
Dag Wieers	dag wieers.com	http://dag.wieers.com/home-made/


CERN Linux		http://linux.web.cern.ch/linux/
Fermi Linux		http://www-oss.fnal.gov/projects/fermilinux/
Gstreamer		http://gstreamer.net/
JPackage		http://www.jpackage.org/
KRUD		http://www.tummy.com/krud/
Owl River Company		ftp://ftp.owlriver.com/pub/local/ORC/
Wirex		http://www.wirex.com/products/immunixos/

We may have missed one of which you are aware. Please let us know the details.

Additional distribution packagers we watch or are aware of (alphabetical order)
cAos		http://caosity.org/
fedora - Red Hat sponsored		http://fedora.redhat.com/
rhel-rebuild		http://www2.uibk.ac.at/zid/software/unix/linux/rhel-rebuild-l.html
Rocks		http://rocks.npaci.edu/
whitebox		http://www.beau.org/~jmorris/linux/whitebox/
Vermillion		http://www.kainx.org/vermillion/ - also: Mezzanine http://www.kainx.org/mezzanine/

Centos oriented adjuncts		centosplus within centos.org dag.wieers.com/packages/ centos.karan.org dev.centos.org ftp.owlriver.com

More archival matter:

Initial "Fedora Community Proposal" v0.0.1 - November 11th, 2002
process comments, valediction for now - (mailing list copy) -- "_warren- Nobody replied, so I'm just going to go ahead with it."
Other voices: Enrico on buildsystems

Last modified: Wed, 15 Oct 2008 14:24:12 -0400
http://www.owlriver.com/projects/packaging/index.php