State of the archive

[Daniel Stone]

[Before we get started: here I use 'archive' to refer to the union of
 ftp.{x,freedesktop}.org's collection of Xorg releases, and
 http://xorg.freedesktop.org/releases/.  HTH.]

Hi,
As Kevin and Egbert have intimated on-list, we've been discussing on
xorg_security (as well as a small thread on xf_board) what to do about
the X.Org release archive as it stands.  I've been asked to punt this
thread to xorg@, so here we go.

Currently, the situation is this:
  * the x.org subdomain does not distribute security fixes, nor
    individual releases; 6.9/7.0 were the last releases to see the light
    of x.org.
  * there is currently a very small group with write access to
    ftp.x.org, and ftp.x.o has no association with
    http://xorg.freedesktop.org/releases/.

Anything beyond this point is personal opinion: you've been forewarned.

Currently, http://xorg.freedesktop.org/releases/ is considered
canonical, especially if you judge it by xorg-announce archives.
However, distributing things on x.org is desirable for obvious reasons.
One of the objectives of the slight reshuffle of the archive on annarchy
was to create a root that's acceptable for FTP as well;
ftp.freedesktop.org:/pub/xorg/ is now an archive mirror.  Old releases
are also being distributed now, though they're write-only.

I asked that ftp.x.org be made a CNAME to ftp.freedesktop.org until the
following issues were resolved:
  * lack of timely security updates,
  * inability to publish new modular releases.

The response was that an X.Org machine would continue to serve
ftp.x.org, and that annarchy's archive would be mirrored if it was only
writable by a very small group ('xorg-release' was the strawman).  I
don't believe that this is terribly useful: if you want to compromise
code, it's infinitely easier to insert innocuous-looking rogue code[0]
than to tarnish the archive.

It's also a system I believe is thoroughly unnecessary: if we look to
GNOME and Debian as precedents of how to deal with modular development,
no such gateway is imposed.  Ubuntu and Fedora have minor splits (the
designation of 'core' vs. 'non-core' developers), but given the scale of
the numbers involved, I don't think that's applicable.  I have to
profess ignorance on how other projects work, bar KDE, which is
essentially a monolithic project in disguise.

download.freedesktop.org is a proposal to continue the archive
separation that started when we split cvs.fd.o/anoncvs.fd.o and
svn.fd.o/anonsvn.fd.o.  Basically, you would submit a changes file with
MD5 and SHA1 sums of the affected files, GPG-signed, to an archive
daemon.  The daemon would then perform the necessary verification
(including access checking), and move the files into the archive if
everything was alright.  That also gives you a nice audit trail, which
is currently emulated by the xorg-announce archive and source-based
distributions[1].  Not having general developer access to the archive
machine also helps in the sense that local root exploits don't grant you
unfettered archive access.

However, the minor problem is that no-one's actually *written* it, and
dealing with the archive problem with download.fd.o is solving the wrong
problem: that of x.org remaining a disconnected entity, even after
wresting control from TOG.  That's one reason why I'm not particularly
enthusastic about throwing a weekend and a bit at writing the code and
then auditing it.

My proposal is simple: have an rsync job mirroring
xorg.freedesktop.org::xorg-archive to ftp.x.org.  This would remove the
ugly dichotomy that exists between xorg.freedesktop.org and x.org in
terms of releases.  (You can guess my thoughts on the website also, but
that's another matter entirely ...)

The entire point of kicking this thread to xorg@ from xorg_security@ and
xf_board@ was to encourage open discussion, so please reply with any
constructive opinions you may have.

Cheers,
Daniel

[0]: The example I generally use is the geteuid == 0 vulnerability,
     which no-one noticed.  Not to tarnish Egbert: his intentions were
     obviously pure, and he can code me under the table.
[1]: Gentoo and FreeBSD include MD5 sums of the source tarballs.
     However, I think they also mirror the tarballs as a matter of
     course, so you're not directly hitting the archive.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20060429/964ce35f/attachment.pgp>