Re: setuid/setgid binaries contained in the Debian repository.
On Fri, 1 Aug 2003 21:12:10 -0400, Joey Hess <joeyh@debian.org> said:
> Manoj Srivastava wrote:
>> This seems like a good practice kind of recommendation, not an
>> requirement, and as such, may be better suited to be included in
>> developers reference rather than policy, don't you think?
> I agree that policy can't force developers to do that, but policy is
> already full of such recommendatons:
> 1.
> You should not specify a `Pre-Depends' entry for a package
> before this has been discussed on the `debian-devel' mailing
> list and a consensus about doing that has been reached.
Packaging informatoin, not program behaviour affected by
this. Packaging details are determined by developers, and can be
easily changed.
> 2.
> You must not tag any packages `essential' before this has been
> discussed on the `debian-devel' mailing list and a consensus
> about doing that has been reached.
Packaging informatoin, not program behaviour affected by
this. Packaging details are determined by developers, and can be
easily changed.
> 3.
> You should not tag any packages as belonging to a task before
> this has been discussed on the _debian-devel_ mailing list and
> a consensus about doing that has been reached.
Packaging informatoin, not program behaviour affected by
this. Packaging details are determined by developers, and can be
easily changed.
> 4.
> This will use a default sequence number of 20. If it does not
> matter when or in which order the `init.d' script is run, use
> this default. If it does, then you should talk to the
> maintainer of the `sysvinit' package or post to `debian-devel',
> and they will help you choose a number.
Packaging informatoin, not program behaviour affected by
this. Packaging details are determined by developers, and can be
easily changed.
> 5.
> If this case happens, one of the programs must be renamed. The
> maintainers should report this to the `debian-devel' mailing
> list and try to find a consensus about which program will have
> to be renamed. If a consensus cannot be reached, _both_
> programs must be renamed.
Packaging informatoin, not program behaviour affected by
this. Packaging details are determined by developers, and can be
easily changed.
> 6. (on perms and users) If necessary you may deviate from the
> details below. However, if you do so you must make sure that
> what is done is secure and you should try to be as consistent
> as possible with the rest of the system. You should probably
> also discuss it on `debian-devel' first.
OK, the first issue of this kind.
> 7.
> In this case you should choose an appropriate user or group
> name, discussing this on `debian-devel' and checking with the
> `base-passwd' maintainer that it is unique and that they do not
> wish you to use a statically allocated id instead.
Hmm. I am not sure if program behaviour need be changed much
with user name/uid changes, but I guess there could be exceptions.
> 8.
> It is often worthwhile contacting such authors diplomatically
> to ask them to modify their license terms. However, this can
> be a politically difficult thing to do and you should ask for
> advice on the `debian-legal' mailing list first, as explained
> below.
Packaging informatoin, not program behaviour affected by
this. Packaging details are determined by developers, and can be
easily changed.
> 9.
> When in doubt about a copyright, send mail to
>> debian-legal@lists.debian.org>. Be prepared to provide us with the
> copyright statement.
Packaging informatoin, not program behaviour affected by
this. Packaging details are determined by developers, and can be
easily changed.
> Do you plan to move all these to the developer's reference? It would
> bloat the developer's reference with references to specific sections
> of policy, and leave the policy full of holes with no
> recommendations as to a good course of action or even a mention that
> a given action is potentially hazardous.
You are now talking about putting things into policy that
require maintainerrs to change program behaviour to attain similar
functionality and features; and all the examples you quote are about
packaging details that are under our control completely.
Apples and oranges, really.
manoj
--
"It says he made us all to be just like him. So if we're dumb, then
god is dumb, and maybe even a little ugly on the side." Frank Zappa
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: