On Thu, Dec 02, 1999 at 03:41:34PM -0800, Joey Hess wrote:
> I read through the policy document today, trying to nitpick and find things
> that have changed in current practice. Here's what I found:
>
> * The policy manual uses the term "section" to refer to main, non-us,
> non-free, and contrib. This overloads the term since we typically call
> games, libs, docs, etc, sections. Instead, it calls those things
> subsections. It also uses the term inconsitently:
[...]
> I think this deserves to be cleaned up, but I don't really know what to
> call main, contrib, and non-free. Distributions, maybe?
We'll, since we are adamant that the Debian distribution consists
officially only of "main", this might be a bad idea.
"Category", maybe?
> * The definition of the standard priority says it includes:
>
> and a reasonable
> subset of TeX and LaTeX (if this is possible without X).
>
> Which implies that X is not standard. However, xlib6g and xfree86-common
> are standard. I think the text in the parens should be removed.
Wichert and I were jawboning about this on IRC the other day. As it
stands, lots of packages deliberately violate the part of policy 5.8 that
says:
Some programs can be configured with or without support for the X Window
System. Typically, binaries produced with support for X will need the X
shared libraries to run.
Such programs should be configured with X support, and should declare a
dependency on xlib6g (which contains X shared libraries). Users who wish
to use the program can install just the relatively small xfree86-common
and xlib6g packages, and do not need to install the whole of X.
Do not create two versions (one with X support and one without) of your
package.
Furthermore, lots of folks scream bloody murder about xlib6g and
xfree86-common being standard, which makes their installation very likely
on systems that don't plan to run X servers or clients.
So, I propose the following compromise:
* Downgrade xfree86-common and xlib6g from standard to optional; AND
* Modify section 5.8 to say that creating X and non-X versions of a
package is permissible *ONLY* if the non-X version qualifies for
standard priority. The X-dependent component can have optional or
extra priority.
I'm willing to throw the X haters this bone. But if we adopt this change I
will enforce the second part with an iron fist. (This is also an argument
for making vim standard, I guess, since I'm sure Wichert will not torpedo
vim-tty. :) )
On a completely different subject, I'm not so sure that TeX and LaTeX
should really be standard. I know that they're commonly found on Unix
systems, but so is X. X was excluded from standard, I think, partly
because of its size and partly because not everyone needs a GUI on their
Unix box. But this logic applies to TeX and its derivatives as well; TeX
is very large and not everyone uses their Unix box as a super-powerful
typesetter. Obviously the "not everyone uses their Unix box as a ..." is
an argument that can be run away with, but there are few Debian packages
that rival even mininal X or TeX installations in size, and maybe none with
a priority higher than optional. Joey, you're good at "simple" perl
one-liners that deduce all kinds of scary facts from the available file, so
I'll leave it up to you to verify or refute that. :)
> * "Every package must have exactly one maintainer at a time." This statement
> is violated by so many packages (including dpkg) that it should be removed.
Seconded.
> * This seems self-contradictory. Are you supposed to remove the created
> directories or not?
>
> However, the package should create empty directories below
> `/usr/local' so that the system administrator knows where to place
> site-specific files. These directories should be removed on package
> removal if they are empty.
>
> Note, that this applies only to directories _below_ `/usr/local', not
> _in_ `/usr/local'. The directory `/usr/local' itself may only contain
> the sub-directories listed in FHS, section 4.6. However, you may
> create directories below them as you wish. You may not remove any of
> the directories listed in 4.6, even if you created them.
I agree. Let's make up our minds on this one. Maybe they should be
removed only if they are empty.
> * "Please look very careful at the details." s/careful/carefully/
You make the anal-retentive old English teacher inside me proud, young man.
> * "Any scripts which create files in world-writable directories (e.g., in
> `/tmp') have to use a mechanism which will fail if a file with the
> same name already exists." I can write code that complies with this and is
> still a serious security problem -- the problem is that this sentance
> encourages the naive to write something like:
> if [ ! -e /tmp/foo ]; then
> echo "goodbye, /etc/passwd" >/tmp/foo
> fi
> Which is vunerable to a race. I think it's be better to require that
> it use a "mechanism which will atomically fail ..."
I agree, but an example of how to do this should be included. Many newbie
developers may not know what "atomic" means in an OS context.
(Heck, lots of people don't know what a race condition is.)
> * "If your packages creates or uses configuration files outside of
> `/etc', and it is not feasible to modify the package to use the
> `/etc', you should still put the files in /etc' and create symbolic
> links to those files from the location that the package requires."
>
> "Use the `/etc'" sounds a little weird to me, perhaps s/the//
I agree.
> * "must not overwrite or otherwise mangle the user's
> configuration without asking, must not ask unnecessary questions
> (particularly during upgrades), and otherwise be good citizens."
>
> Just to remove the tiny shred of ambiguity from this sentance, I'd say
> change the end to "and must otherwise be ..."
Agreed.
> * "Do not arrange that the system administrator can only reconfigure the
> package to correspond to their local security policy by changing the
> permissions on a binary. Ordinary files installed by `dpkg' (as opposed to
> conffiles and other similar objects) have their permissions reset to the
> distributed permissions when the package is reinstalled. Instead you should
> consider (for example) creating a group for people allowed to use the
> program(s) and making any setuid executables executable only by that group."
>
> This paragraph seems to be unaware of suidregister. Perhaps it should
> mention it as an alternative.
Really fundamental setuid tools may need an explicit exception clause in
policy; witness the recent sudo upload.
--
G. Branden Robinson |
Debian GNU/Linux | The noble soul has reverence for itself.
branden@ecn.purdue.edu | -- Friedrich Nietzsche
roger.ecn.purdue.edu/~branden/ |
Attachment:
pgpiO4h3uKyS2.pgp
Description: PGP signature