Re: #231538 and module-init-tools

[Frank Lichtenheld]

On Mon, Mar 07, 2005 at 02:11:48AM +0100, Marco d'Itri wrote:
> The release managers explained on IRC that this bugs is actually about
> hppa now, which needs a woody backport of module-init-tools.
> 
> As the module-init-tools maintainer, my position on this is that I do
> not have a woody environment to test backports nor I am inclined to
> spend time on what appears to be a corner case.
> People interested in fixing this are encouraged to do a NMU.

I have already begun to prepare the necessary backports and will publish
them for testing latest in a few days (currently writing some README for
it).

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#298060: (forw) Bug#298060: Please don't install login as setuid root

[Christian Perrier]

Quoting Joey Hess ([EMAIL PROTECTED]):
> Has anyone looked at shadow's existing changelog?

Honestly, no..:-)

> see shy jo (hurrah for changelog abuse!)

Yep. Sometimes this helps especially for packages where Debian
specific changes are noticeable.

Well, about this issue, I think I'll delay this to post-sarge, for the
day we (the shadow maintenance team which is currently very quiet) we
dill with the huge bug log of this package.

To all people who bringed their advices about this issue : thank you
very much. Feel free to continue giving input, especially after Matt's
comments. The more input we have, the best decision we will make
(maybe with the help of the Technical Comittee if this happens to be
too controversial).

-- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd build order [Was: arm buildd holdup?]

[Hamish Moffatt]

On Sun, Mar 06, 2005 at 10:50:54PM +0100, Kurt Roeckx wrote:
> On Mon, Mar 07, 2005 at 08:27:53AM +1100, Hamish Moffatt wrote:
> > 
> > That's useful to know, but doesn't seem to be correct in the arm case at
> > least.
> > 
> > 1. geda-gschem, speex and wipl are all out-of-date.
> > 2. geda-gschem, speex and wipl are all priority low.
> 
> That's urgency low, and as I said, has nothing to do with it.

You're right. I meant to say priority optional.

> The documentation says that section is ordered alphabetically,
> however, this is wrong.  There is a list of the section each
> having a value.

OK, that explains the behaviour.

> > What's the purpose of sorting by section in the ordering?
> They are also an ordering of what is most important.

Isn't the priority sufficient to do that? What makes sound more
important than electronics?

It's a bit demotivating to be continually trumped by equally optional
packages, especially as packages are being added to the top of queue 
quicker than they're being pulled off. geda-gschem is now #52.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: freezing source packages that produce udebs

[Martin Michlmayr]

* Joey Hess <[EMAIL PROTECTED]> [2005-03-05 17:58]:
> I've added packages to the base freeze that produce udebs in
> addition to debs. This is to avoid propigation of udeb sources to
> testing if the d-i release schedule does not allow the udeb to also
> propigate. As has already happened in at least one case (cdebconf).
> I left off a few packages that produce udebs that are not used, so
> these are the newly frozen packages:

I was just wondering if you've privately informed the maintainers of
these packages.  I agree with this freeze but the maintainers should
be told directly as they might not follow -release or -boot.
-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: (forw) Bug#298060: Please don't install login as setuid root

[Matt Zimmerman]

On Sun, Mar 06, 2005 at 04:34:32PM -0800, Joey Hess wrote:

> Has anyone looked at shadow's existing changelog?
> 
>   * /bin/login is suid root for several good reasons. For one, it allows
> daemons that use it to run as non-root. This is a good thing since it
> means only one program is running as root, and not several. closes: #17911
> 
>  -- Ben Collins <[EMAIL PROTECTED]>  Sun, 31 Dec 2000 14:33:47 -0500

Is there anything which does this other than telnetd?

I'm more than willing to consider telnetd a legacy, insecure-by-design
component for which it is justified to require a non-default configuration.

-- 
 - mdz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

#231538 and module-init-tools

[Marco d'Itri]

The release managers explained on IRC that this bugs is actually about
hppa now, which needs a woody backport of module-init-tools.

As the module-init-tools maintainer, my position on this is that I do
not have a woody environment to test backports nor I am inclined to
spend time on what appears to be a corner case.
People interested in fixing this are encouraged to do a NMU.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: (forw) Bug#298060: Please don't install login as setuid root

[Joey Hess]

Has anyone looked at shadow's existing changelog?

  * /bin/login is suid root for several good reasons. For one, it allows
daemons that use it to run as non-root. This is a good thing since it
means only one program is running as root, and not several. closes: #17911

 -- Ben Collins <[EMAIL PROTECTED]>  Sun, 31 Dec 2000 14:33:47 -0500

-- 
see shy jo (hurrah for changelog abuse!)


signature.asc
Description: Digital signature

New version of nvi for sarge

[Steve Greenland]

I just uploaded a new version of nvi (-22) that fixes
some potential security issues in the init script. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298114 for details.
Unlike the proposed patch, the uploaded version does *not* delete files
for "non-regular" users, but simply sends all e-mails to the owner of
the file, rather than the putative destination in the recovery header.

Since this does not touch the actual nvi code, but only the init script,
I think it's safe for inclusion.

Ah, it also includes a fix to the postinst that ensures the vi
recovery file directory (/var/tmp/vi.recovery) is created with proper
permissions. Again, not much potential for regression.

Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: please requeue gnucash

[Steve Langasek]

Thomas,

On Sat, Mar 05, 2005 at 02:01:03PM -0800, Thomas Bushnell BSG wrote:

> This is the third time of asking.

I don't think there's any need to send multiple requests; the mail system on
buildd.debian.org does run a reliable MTA, even if buildd maintainers may
not actively reply to messages sent there.

> Please requeue gnucash for rebuilding on arm and mipsel.  If it
> doesn't get requeued, I'm going to need to make a spurious extra
> upload to get it built, which will increase load on all the buildds.
> This is surely not the best solution, but it is the only one if it
> doesn't get handled the right way.

This package had already been requeued on mipsel:

gnome/gnucash_1.8.10-7: Needs-Build [extra:out-of-date]
  Previous state was Building until 2005 Mar 06 13:23:22

http://buildd.debian.org/stats/?arch=mipsel&state=Needs-Build

However, mipsel building is running at less than full capacity due to
hardware downage while the local admins have both been unavailable.  There
are 304 packages ahead of gnucash in the queue according to
.

It has not been requeued on arm yet, but arm is down to a single buildd
whose chroot has only just been fixed for the xfree86-common breakage this
afternoon; and arm also has a backlog of 100+ packages that need building.
Please be patient, this is another case where local buildd admins will have
to intervene before it will be built.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: (forw) Bug#298060: Please don't install login as setuid root

[Steve Langasek]

On Sat, Mar 05, 2005 at 03:34:58PM +0100, Christian Perrier wrote:
> Security and release teams, may I have your advice about this suggestion?

> As you may know, I currently act as maintainer for the shadow package,
> but I'm also aware of my own weaknesses when it comes at security (and
> security-related) issues so I prefer getting the advice of more
> competent people.

> Given that installing login non setuid has been blessed for Ubuntu,
> I'm inclined to follow the suggestion, but doing so close to a release
> is maybe not wise.so I'm seeking for advices..:-)

Even when this feature was novel to me, I never found it useful.  I wouldn't
miss it, and obviously the security folks wouldn't; perhaps other people
may, so it's probably reasonable to let such a change age in unstable for a
bit to give them a chance to object and explain why this is actually useful
(since no one else can think of a reason).

-- 
Steve Langasek
postmodern programmer

> - Forwarded message from Martin Pitt <[EMAIL PROTECTED]> -
> 
> Subject: Bug#298060: Please don't install login as setuid root
> Reply-To: Martin Pitt <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Date: Fri, 4 Mar 2005 12:39:11 +0100
> From: Martin Pitt <[EMAIL PROTECTED]>
> To: Debian Bug Tracking System <[EMAIL PROTECTED]>
> 
> Package: login
> Version: 1:4.0.3-30.9
> Severity: wishlist
> Tags: patch
> 
> Hi!
> 
> /bin/login is currently installed setuid root, which is absolutely not
> necessary and only a potential security threat. In Ubuntu we install
> it as 0755 for ages now without any problems.
> 
> Trivial patch, but for the record:
> 
>   http://patches.ubuntu.com/patches/shadow.login-nosuid.diff
> 
> Please consider making this change for Debian, too.
> 
> Thanks,
> 
> Martin
> 
> -- 
> Martin Pitt   http://www.piware.de
> Ubuntu Developerhttp://www.ubuntulinux.org
> Debian GNU/Linux Developer   http://www.debian.org
> 
> 
> 
> - End forwarded message -
> 
> -- 
> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: buildd build order [Was: arm buildd holdup?]

[Kurt Roeckx]

On Mon, Mar 07, 2005 at 08:27:53AM +1100, Hamish Moffatt wrote:
> 
> That's useful to know, but doesn't seem to be correct in the arm case at
> least.
> 
> 1. geda-gschem, speex and wipl are all out-of-date.
> 2. geda-gschem, speex and wipl are all priority low.

That's urgency low, and as I said, has nothing to do with it.

> 3. geda-gschem is section electronics.
>wipl is section net.
>speex is section sound.
> 
> 4. geda-gschem < speex < wipl

Package: geda-gschem
Priority: optional
Section: electronics

Package: speex
Priority: optional
Section: sound

Package: wipl
Priority: optional
Section: net

They're all priority optional, so we move to the section.

The documentation says that section is ordered alphabetically,
however, this is wrong.  There is a list of the section each
having a value.

It's ordered like this:
libs, debian-installer, base, devel, ..., 
net, ..., sound, ..., electronics, ...

So we first get wipl, then speex, then geda-gschem.  And this
seems to agree with what you see.

> What's the purpose of sorting by section in the ordering?

They are also an ordering of what is most important.

Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: buildd build order [Was: arm buildd holdup?]

[Hamish Moffatt]

On Sun, Mar 06, 2005 at 01:55:51PM +0100, Kurt Roeckx wrote:
> On Sun, Mar 06, 2005 at 10:52:41PM +1100, Hamish Moffatt wrote:
> > What is the ordering criteria on the buildds?
> 
> According to the documentation:
> 
> The packages are ordered by the following criteria (in
> this order):
> 
>  - out-of-date/uncompiled (the former come first)
>  - priority (e.g. "required" before "optional")
>  - section (alphabetically)
>  - package name (alphabetically)
[..]
> Basicly, when there are no new/uncompiled packages involved, the
> order is by priority, then section, then alphabetically.

That's useful to know, but doesn't seem to be correct in the arm case at
least.

1. geda-gschem, speex and wipl are all out-of-date.
2. geda-gschem, speex and wipl are all priority low.

3. geda-gschem is section electronics.
   wipl is section net.
   speex is section sound.

4. geda-gschem < speex < wipl

Yet wipl was uploaded yesterday and is #9, speex is #19, and
geda-gschem is #36 (and slipping).

What's the purpose of sorting by section in the ordering?

I suppose the real problem is that there doesn't seem to be any
progress on the queue.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#298060: (forw) Bug#298060: Please don't install login as setuid root

[Christian Perrier]

> (what does this have to do with debian-release?)

Because I was wondering whether such change would be appropriate to
have in sarge and I wanted to get the wise advice of our release
managers...:)


-- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: freezing source packages that produce udebs

[Thiemo Seufer]

Geert Stappers wrote:
> On Sat, Mar 05, 2005 at 05:58:05PM -0800, Joey Hess wrote:
> > I've added packages to the base freeze that produce udebs in addition to
> > debs. This is to avoid propigation of udeb sources to testing if the d-i
> > release schedule does not allow the udeb to also propigate. As has
> > already happened in at least one case (cdebconf). I left off a few
> > packages that produce udebs that are not used, so these are the newly
> > frozen packages:
> > 
> > bogl brltty busybox-cvs cdebconf console-data dash devmapper dhcp dhcp3
>
> > discover1 discover1-data dmidecode e2fsprogs fribidi iso-codes jfsutils
> > libdebian-installer linux-ntfs lvm2 mdadm mii-diag module-init-tools
> > pcmcia-cs raidtools2 reiserfsprogs slang util-linux wireless-tools
> > xfsprogs network-console
> 
> What do need from 'dhcp' that is not in 'dhcp3' ?

dhclient, IIRC. The one in dhcp3 is much larger in size.


Thiemo


signature.asc
Description: Digital signature

Re: freezing source packages that produce udebs

[Joey Hess]

Geert Stappers wrote:
> On Sat, Mar 05, 2005 at 05:58:05PM -0800, Joey Hess wrote:
> > I've added packages to the base freeze that produce udebs in addition to
> > debs. This is to avoid propigation of udeb sources to testing if the d-i
> > release schedule does not allow the udeb to also propigate. As has
> > already happened in at least one case (cdebconf). I left off a few
> > packages that produce udebs that are not used, so these are the newly
> > frozen packages:
> > 
> > bogl brltty busybox-cvs cdebconf console-data dash devmapper dhcp dhcp3
>
> > discover1 discover1-data dmidecode e2fsprogs fribidi iso-codes jfsutils
> > libdebian-installer linux-ntfs lvm2 mdadm mii-diag module-init-tools
> > pcmcia-cs raidtools2 reiserfsprogs slang util-linux wireless-tools
> > xfsprogs network-console
> 
> What do need from 'dhcp' that is not in 'dhcp3' ?
> 
> Cheers
> Geert Stappers
> (who thinks that dhcp is obsoleted by dhcp3)

I know we use dhcp-client-udeb from dhcp. I forget if we also use dhcp3.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: (forw) Bug#298060: Please don't install login as setuid root

[Matt Zimmerman]

On Sun, Mar 06, 2005 at 05:10:59AM -0600, Bill Allombert wrote:

> On Sat, Mar 05, 2005 at 10:56:45PM -0800, Matt Zimmerman wrote:
> > FWIW, We've been doing this for some time in Ubuntu, and no one has
> > missed it.  In this age of pseudoterminals and single-user systems...
> 
> Because that is the targeted users of Ubuntu.

If someone told you that, they were misinformed.

> Is there a real security benefit ? Is the login implementation in Debian
> known to have security flaws ?

Those two questions are orthogonal, but the answer to the first is "yes".
Removing privilege this way is one of the few ways to provide a guarantee of
security: it would become impossible for any bug (discovered or
undiscovered) in login to result in a root compromise, except where it is
explicitly given root privileges (which I believe is only true on the
console per default).

> The bug report is not completly accurate: it is necessary for login to be
> suid root if you want to use it the way mentionned in the manpage:
> 
>Typically,  login  is  treated  by the shell as exec login
>which causes the user to  exit  from  the  current  shell.

There are a dozen ways to obtain the same result, without this setuid
program.

It makes little difference to me in practice whether this change is made or
not, but I do consider it appropriate and reasonable.

(what does this have to do with debian-release?)

-- 
 - mdz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

buildd build order [Was: arm buildd holdup?]

[Kurt Roeckx]

On Sun, Mar 06, 2005 at 10:52:41PM +1100, Hamish Moffatt wrote:
> Goswin wrote:
> > Need-build is a good sign. http://buildd.net/ shows you are on place
> > 37 out of 120. I suggest just waiting unless the buildd has stoped
> > altogether.
> 
> What is the ordering criteria on the buildds?

According to the documentation:

The packages are ordered by the following criteria (in
this order):

 - out-of-date/uncompiled (the former come first)
 - priority (e.g. "required" before "optional")
 - section (alphabetically)
 - package name (alphabetically)

Note the the priority has nothing do with with the urgency of the
upload, it has no effect on it.

The documentation seems to be a litte out of date, and before
those 4, there is also a rule that lists all packages of higher
priority than standard before the rest.

Basicly, when there are no new/uncompiled packages involved, the
order is by priority, then section, then alphabetically.


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: arm buildd holdup?

[Hamish Moffatt]

Goswin wrote:
> Need-build is a good sign. http://buildd.net/ shows you are on place
> 37 out of 120. I suggest just waiting unless the buildd has stoped
> altogether.
What is the ordering criteria on the buildds?
I notice that speex (for example) was uploaded on Feb 26 with priority 
low and it's 7th on the arm list, but geda-gschem was uploaded on Feb 23 
with priority low and it's 35th. quodlibet was uploaded on March 4 (also 
priority low) and it's 6th.

Is it FIFO within the priority levels? I would've expected so.
thanks,
Hamish
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: (forw) Bug#298060: Please don't install login as setuid root

[Bill Allombert]

On Sat, Mar 05, 2005 at 10:56:45PM -0800, Matt Zimmerman wrote:
> On Sat, Mar 05, 2005 at 03:34:58PM +0100, Christian Perrier wrote:
> 
> > Security and release teams, may I have your advice about this suggestion?
> > 
> > As you may know, I currently act as maintainer for the shadow package,
> > but I'm also aware of my own weaknesses when it comes at security (and
> > security-related) issues so I prefer getting the advice of more
> > competent people.
> > 
> > Given that installing login non setuid has been blessed for Ubuntu,
> > I'm inclined to follow the suggestion, but doing so close to a release
> > is maybe not wise.so I'm seeking for advices..:-)
> 
> FWIW, We've been doing this for some time in Ubuntu, and no one has missed
> it.  In this age of pseudoterminals and single-user systems...

Because that is the targeted users of Ubuntu. Debian as a much wider range
of use than single-user systems. 

Is there a real security benefit ? Is the login implementation in Debian
known to have security flaws ?

The bug report is not completly accurate: it is necessary for login to be
suid root if you want to use it the way mentionned in the manpage:

   Typically,  login  is  treated  by the shell as exec login
   which causes the user to  exit  from  the  current  shell.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: freezing source packages that produce udebs

[Geert Stappers]

On Sat, Mar 05, 2005 at 05:58:05PM -0800, Joey Hess wrote:
> I've added packages to the base freeze that produce udebs in addition to
> debs. This is to avoid propigation of udeb sources to testing if the d-i
> release schedule does not allow the udeb to also propigate. As has
> already happened in at least one case (cdebconf). I left off a few
> packages that produce udebs that are not used, so these are the newly
> frozen packages:
> 
> bogl brltty busybox-cvs cdebconf console-data dash devmapper dhcp dhcp3
   
> discover1 discover1-data dmidecode e2fsprogs fribidi iso-codes jfsutils
> libdebian-installer linux-ntfs lvm2 mdadm mii-diag module-init-tools
> pcmcia-cs raidtools2 reiserfsprogs slang util-linux wireless-tools
> xfsprogs network-console

What do need from 'dhcp' that is not in 'dhcp3' ?

Cheers
Geert Stappers
(who thinks that dhcp is obsoleted by dhcp3)



signature.asc
Description: Digital signature