> the debian policy states that you shouldn't make suid programs unreadable to
> the world; the idea behind ever doing such a thing on nonfree systems is
> that the program may have security holes that could be exploited by users
> that examined the program carefully. the policy tells you not to d
On Mon, Feb 01, 1999 at 08:45:05PM +0100, Marcus Brinkmann wrote:
> + DEB_*_ARCHthe Debian architecture
> -+ DEB_*_GNU_SYSTEM the GNU style architecture specification string
> -+ DEB_*_GNU_ARCHthe CPU part of DEB_*_GNU_SYSTEM
> -+ DEB_*_GNU_OS the OS part of DEB_
Hi,
==
Accepted
if the amendment is accepted, the bug is marked forwarded, until
it is actually integrated into Policy and uploaded and moved into
the archive, at which time the bug is retitled "
Hello,
I ask the policy group to come to a decision about my amendment to change
the architecture query possibilities in the package build process. I
proposed the change two weeks ago, and the discussion period is now over. As
there was no discussion in the last week, I think it is not needed to
the debian policy states that you shouldn't make suid programs unreadable to
the world; the idea behind ever doing such a thing on nonfree systems is
that the program may have security holes that could be exploited by users
that examined the program carefully. the policy tells you not to do thes
b
On Mon, 1 Feb 1999, John Goerzen wrote:
>
> > I wouldn't have those +ws in place, though, unless they're necessary.
>
> Well the -w can be taken off, but as I said, it does need to be setuid.
*grin*
That 's' was a pluralisation, not a setuid. I meant 'there's no need for
the directory or execu
On Mon, Feb 01, 1999 at 06:24:22PM +, Jules Bean wrote:
> That solution works well for me.
>
> Although I'd call it /usr/lib/listar, probably. (Did we dump
That's what I meant; /usr/lib/listar/restricted-executables/ or some such.
> /usr/libexec? Oh well, I'm sure there was a reason..).
On Mon, 1 Feb 1999, John Goerzen wrote:
>
> The solution that I have come up with is to create a special directory in
> its /usr/lib area:
>
> drwxrwx--- listar.daemon restricted-executables/
>
> Then, in there, have the binary:
>
> -rwsrwsr-x listar.listar listar
>
> How does that sound to ev
Hello all,
Section 4.9 of the Debian policy manual specifically permits deviance from
the defined behavior when necessary; however, I would like to discuss a
situation not contemplated by that section.
The situation is this. There is a mailing list management program that
needs to run setuid to
On Mon, Feb 01, 1999 at 01:26:03AM -0800, Joey Hess wrote:
> > * To decide which of the two is better, cooler, or nicer, and mark the
> > other as extra.
> >
> > * Or to repackage them so that they are compatible, like pgp-i and pgp-us
> > (update-alternatives is our friend).
>
> Or more likely w
On Sat, 30 Jan 1999, Joseph Carter wrote:
> A number of optional packages should be optional and YES they should
> conflict. An example would be gs and gs-aladdin.
It's not true they "should" conflict.
We have the update-alternatives mechanism which allows
pgp-i and pgp-us not to conflict at ea
Santiago Vila wrote:
> * To decide which of the two is better, cooler, or nicer, and mark the
> other as extra.
>
> * Or to repackage them so that they are compatible, like pgp-i and pgp-us
> (update-alternatives is our friend).
Or more likely when the first option fails in a flame war and the se
12 matches
Mail list logo
