[Pkg-games-devel] Another joiner!

[Moritz Muehlenhoff]

Miriam Ruiz wrote:
> >   This is largely because many games are setgid(games) so
> >  they can write to global highscore files.  (Other cases
> >  are mostly gone.  Previously many games were setuid(0) to
> >  interface with svgalib, etc.)
> > 
> >   I've been tempted more than once to start a debate about
> >  global highscores.  I think that too many games are setgid
> >  for no other reason, and that in many many cases a Debian
> >  installation used for games is going to be a single-user system.
> 
> In my opinion setuid(0) should not be used for that, as it opens a potential
> security hole which in most of the games is quite real, as they're not really
> usually designed for handling attacks (buffer overflows,  badly handled
> temporary files,...)
> 
> It would be nice to develop some guidelines to handle points like that, as
> they're quite common to many games.

As Steve already explained there's a games group for this. Many of these could
indeed by fixed to have the setgid/games removed, but a security problem that
leads to a group games privilege escalation still isn't a big deal.
But for Etch we should get rid of all games that are configured setuid root
for svgalib, svgalib just isn't useful anymore nowadays. (Except the svgalib-
only games obviously) 

> >   I would imagine that one of the goals of the games list would
> >  be to update each game so that any member could upload them?
> >  Kinda like how GNOME, etc, work.  Is that the case?
> 
> Well, that's the idea I have in mind for the group, like setting up a
> subversion repository and maintaining them in a collaborative way, something
> like KDE team does or so. This has lots of advantages over the one package-one
> developer approach.

We should use a
Maintainer: Debian Games Group <pkg-games-devel at lists.alioth.debian.org>
entry with Uploaders: foo for the persons performing uploads.

But I don't think it's useful to keep all packages in SVN, that's way too much
overhead. It might be very useful for some core libs or for collaboratively
bringing a new program in shape for an initial upload, but for day-to-day
maintenance this seems like too much overhead.

Cheers,
        Moritz