Re: stack protection

[Russell Coker]

On Sat, 23 Aug 2003 07:02, Milan P. Stanic wrote:
> On Thu, Aug 21, 2003 at 09:39:53AM +0200, Xavier Roche wrote:
> > Note that some options are sometimes incompatible with some packages:
> > restrictions on kmem ('Deny writing to /dev/kmem, /dev/mem, and
> > /dev/port') prevent lm_sensors from working properly with my server. But
>
> "cat /dev/zero > /dev/mem" is a feature and not a bug, but today
> more and more people disagree.

Allowing the system administrator to write to /dev/mem as part of debugging 
the kernel is a feature.

Allowing the dhcp server to write to /dev/mem because it's UID 0 and Unix 
security sucks is a bug.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: Thank you!

[gtaylor+bounceybouncey]

You've sent me a message about which my email software isn't quite
clear and which my language analysis program thinks looks like junk
mail.  Odds are that one of several things is the case:

 - You have indeed sent me junk mail, or

 - You have sent me a formal-sounding form letter, or

 - You have send me a message in a language other than English.

I will never see the message you have sent me.  If you really do want
to contact me, you can do one of two things:

 - Do the opposite of what you did that made my software reject your
   message.  Ie, don't send me junk mail, send me a nice informal
   hand-tooled letter, or write in English.

 - Obtain a time-limited address from my web page and send me any kind
   of message you like.  The URL should appear in my signature below.

If you prove to be an actual human, I'll add you to my list of known
correspondants, and you won't ever have to worry about this again.

-- 
Grant Taylor -- http://www.picante.com/~gtaylor/

[GWAVA:1dr1x11d] Subject filter message notification

[GWAVA]

This is an automated Notification e-mail message from GWAVA.

The message you sent, from the address debian-devel@lists.debian.org

to [EMAIL PROTECTED]

Concerning: Re: That movie

Was not delivered because it contained content not accepted by the e-mail
system in use at the intended recipient's organization.

The message contained the following text:

%%FilterContent

Re: /etc/mailname same as /etc/hostname

[Dan Jacobson]

> "A" == Andreas Metzler <[EMAIL PROTECTED]> mailed me:

A> On Wed, Aug 20, 2003 at 11:06:12AM +0800, Dan Jacobson wrote:
>> If /etc/mailname is the same as /etc/hostname, can I remove
>> /etc/mailname perhaps one day? Both say jidanni.org .

A> No, they serve different purposes. Quoting policy 11.6:[...]

I see. OK, I just did
cd /etc && cmp hostname mailname && rm mailname && ln -s hostname mailname
[I hope that's OK.]

Re: ruby1.6 and ruby-defaults 1.6 is uploaded (Re: [RFC] Debian ruby policy (Re: Fw: Re: Ruby 1.8 transition plan; debian-ruby))

[Fumitoshi UKAI]

At Sat, 23 Aug 2003 03:59:53 +0900,
Fumitoshi UKAI wrote:

> I uploaded ruby1.6 and ruby-defaults (1.6.8-6) now.
> Packages built from ruby1.6 source package is simply renamed from 
> ruby 1.6.8-5.
> 
> I plan ruby 1.8 transition:
> 
> - Wait a while until ruby1.6 and ruby-defaults are installed, 
>   because these are NEW packages.

These entered in queue/new.
You can also get them from http://pkg-ruby.alioth.debian.org/deb
or apt-get

 deb http://pkg-ruby.alioth.debian.org/deb ./
 deb-src http://pkg-ruby.alioth.debian.org/deb ./

Regards,
Fumitoshi UKAI

Re: ftp.gnu.org cracked

[Andreas Metzler]

Scott James Remnant <[EMAIL PROTECTED]> wrote:
> [ Moved to debian-devel, I don't think this is relevant to private as
>  the GNU crack is well publicised ]

> On Mon, 2003-08-18 at 14:58, Matt Zimmerman wrote:
[...] 
>> If we're going to make a statement about it, we should have some facts to
>> release.  For example, if someone would like to verify the validity of the
>> GNU source tarballs that we ship against the checksums published by GNU,
>> that would be great.

> No problem, this is only a quick run -- others may find ways to improve
> this script somewhat.
[...]
> The script I used is attached, it takes the before-2003-08-01.md5sums
> file from the GNU ftp site (run through gpg to remove signature) as
> either stdin or a command-line argument.
[...]

The corresponding output for files from alpha.gnu.org is much shorter:

   autoconf: autoconf_2.57.orig.tar.gz OK.
!! coreutils: coreutils_4.5.3.orig.tar.gz NOT OK 
(bc59cb94381dcda083e1cdf2f054bf24 != 2d520532c40d5965024f7cc31a7c0ab7)
!! coreutils: coreutils_4.5.6.orig.tar.gz NOT OK 
(2bb41d18c38ab909d02875866e7f2b08 != a22e7e148cc76995dac17ac302b5602f)
!! coreutils: coreutils_5.0.90.orig.tar.gz NOT OK 
(dbf2126651fe7f09aef0758d3c49a245 != e35fa79775ba0e1b973f13d06336287c)
   textutils: textutils_2.0.orig.tar.gz OK.
   findutils: findutils_4.1.20.orig.tar.gz OK.
   gpaint: gpaint_0.2.2.orig.tar.gz OK.
   gzip: gzip_1.3.5.orig.tar.gz OK.
   libidn: libidn_0.1.14.orig.tar.gz OK.
   tar: tar_1.13.25.orig.tar.gz OK.
   vcdimager: vcdimager_0.7.14.orig.tar.gz OK.

   cu andreas

This is an alert from the blondes

[airhead]

*** Shutterfly detected a hostile content in this email. ***


Time: 23 Aug 2003 02:13:21
Scan result: Mail modified to remove malicious content
Protocol: SMTP in
File Name\Mail Subject: mail_1061622913: Thank you!
Source: debian-devel@lists.debian.org
Destination: [EMAIL PROTECTED]
Details: details.pif  Msg #715 - The file details.pif is on the Known Vandal 
Files List.

Re: /etc/shells management

[Bastian Blank]

On Fri, Aug 22, 2003 at 10:56:22PM -0400, [EMAIL PROTECTED] wrote:
> /etc/shells is no longer a config file, but is maintained by the
> add-shell and remove-shell programs.  So, if a package contains
> something that the maintainer thinks ought to be a valid login shell,
> it's postinst should, (on initial install only, to allow a sysadmin to
> take it out again), run:

i think the scripts should follow the update-X naming schema.

bastian

-- 
I'm a soldier, not a diplomat.  I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9


pgpMAjhnKJKE1.pgp
Description: PGP signature

Re: stack protection

[Milan P. Stanic]

On Sat, Aug 23, 2003 at 03:13:25PM +1000, Russell Coker wrote:
> On Sat, 23 Aug 2003 07:02, Milan P. Stanic wrote:
> > On Thu, Aug 21, 2003 at 09:39:53AM +0200, Xavier Roche wrote:
> > > Note that some options are sometimes incompatible with some packages:
> > > restrictions on kmem ('Deny writing to /dev/kmem, /dev/mem, and
> > > /dev/port') prevent lm_sensors from working properly with my server. But
> >
> > "cat /dev/zero > /dev/mem" is a feature and not a bug, but today
> > more and more people disagree.
> 
> Allowing the system administrator to write to /dev/mem as part of debugging 
> the kernel is a feature.

UID 0 must have rights to do everything. root can "format" filesystem,
by mistake or by intention.

> Allowing the dhcp server to write to /dev/mem because it's UID 0 and Unix 
> security sucks is a bug.

The problem isn't with UID 0, but with bugs in software.

I think that the problem cannot be solved in wrong place. It isn't
possible to have secure DHCP server by fixing kernel, but by writing
secure (OK, with less bugs) DHCP server.

Re: stack protection

[Cameron Patrick]

On Sat, Aug 23, 2003 at 11:36:04AM +0200, Milan P. Stanic wrote:

| > Allowing the dhcp server to write to /dev/mem because it's UID 0 and Unix 
| > security sucks is a bug.
| 
| The problem isn't with UID 0, but with bugs in software.

No.  The problem is an insecure design that forces the DHCP server to
have root priviledges.  A finer-grained security would give the DHCP
server /just/ enough rights to send and receive the network packets it
wants and only fiddle with the files that it actually needs
(/var/lib/dhcp/).

| I think that the problem cannot be solved in wrong place. It isn't
| possible to have secure DHCP server by fixing kernel, but by writing
| secure (OK, with less bugs) DHCP server.

A kernel with the ability to lock down processes even further would mean
that a buggy DHCP server couldn't be exploited to e.g. scribble all over
/dev/mem.  This is what systems like grsecurity or SE Linux are trying
to do.  Which is not to say that less-buggy software is a bad goal; but
the reality is that programmers are human, and /do/ make mistakes.

Cameron.

Correct Directory for networkboot clients

[Daniel J. Priem]

Where should i place the root directory for networkbooting clients ?
i'm packing www.ltsp.org I don't know where to place the /
Im thinking about /usr/ltsp/ or /usr/share/ltsp/

Re: FTBFS: architecture all packages

[Goswin von Brederlow]

Osamu Aoki <[EMAIL PROTECTED]> writes:

> On Fri, Aug 22, 2003 at 10:57:53PM +0200, Goswin von Brederlow wrote:
> > Colin Watson <[EMAIL PROTECTED]> writes:
> ...
> > > Have you ever built kde-i18n? When I last NMUed it it took something
> > > like nine hours for my laptop to build it, and my laptop isn't all
> > > *that* wimpy.
> > 
> > Not surprising given its a ~650 MB sources. Unpacking and packaing
> > alone will take hours on m68k I guess.
> > 
> > But an idle buildd is idel so no harm in him building it. On the other
> > hand you downloading 200 MB and uploading 400 MB with a 38400 modem
> > would realy hurt. Well not you but someone only having a 38400
> > connect.
> 
> Build package on debian machine with fast connection by accessing
> with ssh.  Then copy 2 small files (dsc, changes) to the local machine
> and sign.  Copy back them and upload.  You do not need to upload rom
> your local machine.  
> 
> So your bandwidth is not key issue here.

You know what online time costs for modem users? :)

MfG
Goswin

Re: stack protection

[Goswin von Brederlow]

Brian May <[EMAIL PROTECTED]> writes:

> On Fri, Aug 22, 2003 at 10:05:13PM +0200, Goswin von Brederlow wrote:
> > Depending on the size of udev it might be on the initrd or not.
> > If its not then you need a lot of /dev entries to mount the real root
> > device and get udev started or a extra script that created node on the
> > fly from /proc/something.
> 
> Actually, no you don't.
> 
> The real root is created "on the fly" with mknod with the major,minor
> numbers supplied from the kernel (/proc/sys/kernel/real-root-dev).
> 
> See /usr/share/initrd-tools/init for details.
> 
> (at least thats how I read the code, I don't claim to be an expert on
> this file, under certain circumstances it would appear to parse the
> /proc/cmdline directly).

If you know what the root is.

For debix I have a minimal ramdisk that will search for cdroms and
tries to find the right CDrom in them. Once I have the cdrom size is
not realy a problem anymore.

But what devices do i have to make for all the cdroms, esspecially the
custom ones like the old cdrom on a soundblaster versions.

Having /dev/cdroms is realy a big help searching for a CD. I hope the
same can be done with sysfs.

I guess its time to try to get a linux 2.6 to compile, boot and run
long enough to look around again.

MfG
Goswin

Re: Debian Weekly News - August 19th, 2003

[Josip Rodin]

On Fri, Aug 22, 2003 at 04:43:03PM -0700, Don Armstrong wrote:
> > > But do not attempt to subvert [the Social Contract and DFSG] by
> > > attempting to persuade people that clause 1 of the Social Contract
> > > says things it obviously does not.
> > 
> > If you take Clause 1 of the Social Contract to literally mean that
> > Debian contains nothing save software that is free, then that clause
> > has never been true since it was introduced, since we have always
> > contained many non-software items (documentation, bibles, Linux
> > Gazette issues, RFCs, graphics, wallpapers, sounds, etc.)
> 
> But typically those files have had the same freedoms that software has
> in Debian. In cases where they don't, RC bugs have been filed and
> stinks raised. [IE, for RFC's, and GFDL'ed documentation.]

> I don't really see -legal and/or ftpmaster doing much else than
> conservatively interpreting and acting upon the Social Contract
> and the DFSG.

Let's not pretend that there's suddenly some infinite amount of conservative
morality in starting to interpret the old documents differently from how
they were interpreted when all this Evil and Wrong(tm) non-free
documentation came into Debian. Striving for non-restricted documentation
is a fine thing to do, but the present situation is simply not that
black and white. All those "RC" bugs are still not closed for a reason.

-- 
 2. That which causes joy or happiness.

What does that (from wanna-build stats) mean?

[Joerg Wendland]

Hi,
when looking at [0] I see the following about my python-bz2:

> python/python-bz2_1.1-6: Failed by buildd-caballero [optional:out-of-date]
>   Reasons for failing:
> [Category: none]
> bug #181674, missing build dep on bzip2
>   Previous state was Building until 2003 Aug 13 11:47:54

Does that mean that the build failed (which it indeed did for a bug in
dh_python) and the package is not tried to be rebuilt because of the (long
closed in versions before) bug mentioned aboved?

Thanks, Joerg

[0] http://buildd.debian.org/stats/ia64-all.txt
-- 
Joerg "joergland" Wendland
GPG: 51CF8417 FP: 79C0 7671 AFC7 315E 657A  F318 57A3 7FBD 51CF 8417


pgp6xhxhxBsT0.pgp
Description: PGP signature

Re: Bits from the RM

[Tollef Fog Heen]

* Joe Drew 

| On Fri, 2003-08-22 at 01:42, Tollef Fog Heen wrote:
| > * Teófilo Ruiz Suárez 
| > 
| > | What about Apache? Should we change the apache2 package to apache?
| > 
| > No.  (Wearing apache & apache2 maintainer hat.)
| 
| What are the criteria for the apache package to become Apache 2?

Seamless upgrade without loss of functionality (that includes
modules),

or 

making pigs fly.

(choose one).

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: Correct Directory for networkboot clients

[Goswin von Brederlow]

"Daniel J. Priem" <[EMAIL PROTECTED]> writes:

> Where should i place the root directory for networkbooting clients ?
> i'm packing www.ltsp.org I don't know where to place the /
> Im thinking about /usr/ltsp/ or /usr/share/ltsp/

/usr/share/ltsp// is probably better. Otherwise you can#t boot
different archs from the same server.

MfG
Goswin

Re: /etc/shells management

[Tollef Fog Heen]

* 

| I just uploaded a version of shadow that provides scripts for the
| maintenance of /etc/shells.  I decided very quickly when I became the
| shadow maintainer that I didn't want to (and probably wasn't qualified to
| be) an arbiter of acceptable shells.

Why wasn't this sent to debian-devel-announce instead of just
debian-devel?

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: Correct Directory for networkboot clients

[Ben Armstrong]

On Sat, Aug 23, 2003 at 01:30:55PM +0200, Goswin von Brederlow wrote:
> /usr/share/ltsp// is probably better. Otherwise you can#t boot
> different archs from the same server.

Shouldn't that be /var/lib/ltsp// instead?  I'm assuming the root
filesystem is writable.

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

Re: Correct Directory for networkboot clients

[Daniel J. Priem]

Am Sam, 2003-08-23 um 14.30 schrieb Ben Armstrong:
> On Sat, Aug 23, 2003 at 01:30:55PM +0200, Goswin von Brederlow wrote:
> > /usr/share/ltsp// is probably better. Otherwise you can#t boot
> > different archs from the same server.
> 
> Shouldn't that be /var/lib/ltsp// instead?  I'm assuming the root
> filesystem is writable.
The rootfilesystem is writable but will be normaly not changed. Only on
Startup the configfiles for the client will be created / linked

> 
> Ben
> --
>  ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
>  \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
>   `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
>  [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-- 
Retrieve my key from: 
www.keyserver.de 
blackhole.pca.dfn.de 
horowitz.surfnet.nl 
keyID 7B196671
or send email with subject "fetch key"


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Correct Directory for networkboot clients

[Ben Armstrong]

On Sat, Aug 23, 2003 at 02:38:32PM +0200, Daniel J. Priem wrote:
> The rootfilesystem is writable but will be normaly not changed. Only on
> Startup the configfiles for the client will be created / linked

Still, conceptually, a root filesystem is "state" information for the 
netbootable client.  Even if the default policy is to not change the root 
filesystem, is that written in stone?

Ben
--
 ,-.  nSLUGhttp://www.nslug.ns.ca   [EMAIL PROTECTED]
 \`'  Debian   http://www.debian.org[EMAIL PROTECTED]
  `  [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
 [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

Re: Bits from the RM

[David Weinehall]

On Sat, Aug 23, 2003 at 01:26:20PM +0200, Tollef Fog Heen wrote:
> * Joe Drew 
> 
> | On Fri, 2003-08-22 at 01:42, Tollef Fog Heen wrote:
> | > * Teófilo Ruiz Suárez 
> | > 
> | > | What about Apache? Should we change the apache2 package to apache?
> | > 
> | > No.  (Wearing apache & apache2 maintainer hat.)
> | 
> | What are the criteria for the apache package to become Apache 2?
> 
> Seamless upgrade without loss of functionality (that includes
> modules),
> 
> or 
> 
> making pigs fly.

Pink Floyd already made the latter happen for the cover
for their album Animals.  The pig escaped though, and made it a
beautiful story.

http://www.myputney.co.uk/wandsworth/community-batterseapowerstation.htm
http://www.floydianslip.com/discs/animals.htm


/David
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/

Re: stack protection

[Andreas Barth]

* Milan P. Stanic ([EMAIL PROTECTED]) [030823 11:50]:
> On Sat, Aug 23, 2003 at 03:13:25PM +1000, Russell Coker wrote:
> > Allowing the system administrator to write to /dev/mem as part of debugging 
> > the kernel is a feature.

> UID 0 must have rights to do everything. root can "format" filesystem,
> by mistake or by intention.

Can you explain that to me why? Why must there be a user id that can
do everything? (The only thing UID 0 can't do is to exclude itself from
access to a piece of the system.) Why is it necessary that UID 0 can
tamper with kernel space in cirumvention of the interfaces from the
kernel on a production system after startup? Why is it necessary that
the same UID that can bind to low ports can also read any files?

It's convinient that UID 0 can do that at startup, at development, at
debugging or at system initalization. But not in a running production
environment.


> > Allowing the dhcp server to write to /dev/mem because it's UID 0 and Unix 
> > security sucks is a bug.
 
> The problem isn't with UID 0, but with bugs in software.

Why does each server need to be started by UID 0 and therefor the
startup programm can do everything? Why does my news server need root,
or a dhcp server, or ...? I can't understand that.

I do understand that it is easier to have an almighty UID 0. But I
really would like a system where the existence of UID 0 is no longer
necessary but optional.

> I think that the problem cannot be solved in wrong place. It isn't
> possible to have secure DHCP server by fixing kernel, but by writing
> secure (OK, with less bugs) DHCP server.

I've never seen a programm that's really secure. There are programms
with more bugs or with less bugs. So it's always strictly necessary to
make programms "fail safe", so that failing does as less harm as
possible. A error in a dhcp server should just make dhcp fail, and
have no negative impact on security.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Bits from the RM

[Roland Mas]

Tollef Fog Heen (2003-08-23 13:26:20 +0200) :

> * Joe Drew 

[...]

> | What are the criteria for the apache package to become Apache 2?
>
> Seamless upgrade without loss of functionality (that includes
> modules),
>
> or 
>
> making pigs fly.

1. All you need for that is thrust (see Ginger, Mac and Rocky);
2. Debian prides itself on its web of thrust;
3. therefore the web servers in Debian do provide enough thrust.

...or am I missing something? :-)

Roland.
-- 
Roland Mas

Lord of the rings?  Show us.
European Juggling Convention -- Svendborg, Denmark.  http://ejc2003.dk

Re: Bits from the RM

[Tollef Fog Heen]

* Roland Mas 

| Tollef Fog Heen (2003-08-23 13:26:20 +0200) :

[...]

| > making pigs fly.
| 
| 1. All you need for that is thrust (see Ginger, Mac and Rocky);
| 2. Debian prides itself on its web of thrust;
| 3. therefore the web servers in Debian do provide enough thrust.
| 
| ...or am I missing something? :-)

yes, the pigs.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: Bits from the RM

[Andrew Suffield]

On Sat, Aug 23, 2003 at 03:13:40PM +0200, Roland Mas wrote:
> > making pigs fly.
> 
> 1. All you need for that is thrust (see Ginger, Mac and Rocky);
> 2. Debian prides itself on its web of thrust;
> 3. therefore the web servers in Debian do provide enough thrust.
> 
> ...or am I missing something? :-)

You aren't thrusting hard or often enough.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


pgpuoKc4DXAzK.pgp
Description: PGP signature

Re: stack protection

[Russell Coker]

On Sat, 23 Aug 2003 19:36, Milan P. Stanic wrote:
> > Allowing the system administrator to write to /dev/mem as part of
> > debugging the kernel is a feature.
>
> UID 0 must have rights to do everything. root can "format" filesystem,
> by mistake or by intention.

UID does not have to be the only method of determining access rights.  In SE 
Linux you have the Identity (based on the login name for interactive sessions 
and cron jobs, or system_u otherwise) which determines which roles are 
permitted.  You have the Role which determines which domains are permitted, 
for an Identity that is permitted to use multiple roles there are methods of 
changing roles during a session or of determining which Role to use when 
logging in.  Then you have the Domain which determines the access rights.

When you login to do administrative work by default you will have the context 
root:sysadm_r:sysadm_t as the Identity:Role:Domain.  This will deny you 
access to block devices, when you run mount or mkfs they run in different 
domains which have the access needed to do their job.

Then when you run a daemon it runs in a domain that has only the access needed 
for it's operation, dhcpd_t can do raw network access and bind to UDP port 
67.  named_t can bind to port 53 for TCP and UDP and port 953 for TCP.  
Neither named nor dhcpd can access files under user home directories, read 
/etc/shadow, etc.  Which is a very good thing as both have a bad history.

> > Allowing the dhcp server to write to /dev/mem because it's UID 0 and Unix
> > security sucks is a bug.
>
> The problem isn't with UID 0, but with bugs in software.
>
> I think that the problem cannot be solved in wrong place. It isn't
> possible to have secure DHCP server by fixing kernel, but by writing
> secure (OK, with less bugs) DHCP server.

Writing perfect software is impossible.

For a good defence you want to have multiple levels.  Medieval castles never 
had a single level of defence, they were built on a hill, they were 
surrounded by a moat, they had outer walls and then a fortified keep inside 
so that even filling in the moat and smashing the outer walls would not let 
an attacker win.

If you have only a single level of security then any hole that is found will 
make you lose.  If you have several levels of security then ideally it will 
not be possible to successfully attack you unless holes are found in all 
levels simultaneously, which is a much more difficult and less likely event.

Writing quality software is good.  Having stack protection is good too (the 
original topic of this thread).  But it still doesn't provide as much 
protection as you will really want, SE Linux is still necessary even if you 
run top quality software.

Most Unix daemons are not of the highest quality, consider that they added a 
"-b" switch to start-stop-daemon.  Think about the quality of coding that 
goes into a daemon that doesn't even call the daemon(0,0) library call or 
have equivalent code!


PS  The ptrace exploit code that was released did not work on SE Linux 
systems.  The reason was that the socket access necessary to trigger the 
module load in the exploit code was denied to the user_t domain because it 
was not needed (everything that is not needed is denied by default).  It 
might have been possible to write an exploit to work on SE Linux, but no-one 
did so.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: FTBFS: architecture all packages

[Osamu Aoki]

On Sat, Aug 23, 2003 at 12:55:06PM +0200, Goswin von Brederlow wrote:
> Osamu Aoki <[EMAIL PROTECTED]> writes:
> > So your bandwidth is not key issue here.
> 
> You know what online time costs for modem users? :)

Yes, I moved from US to EU.  It may not be as bad as Japan though :)

If you have few iprepared script to build the package and source is synched by
CVS, it is much faster to build package this way.  I am not suggesting
to do hacking while on line.  ("screen" program is a ppp-user's friend to
let us log off during the long build cycle.)

(If you are a porter, that is different issue. You may have to use the
actual machine to debug it.)

Osamu

Re: Accepted fltk 1.0.11-11.1 (i386 source all)

[Aaron M. Ucko]

Congratulations, you've just broken binary compatibility by
(implicitly) rebuilding with G++ 3.3.  I'm preparing a new NMU that
switches back to G++ 2.95 (except on IA64, which needs 2.95, and HPPA,
which needs 3.0).

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.

Re: /etc/shells management

[Isaac To]

> "Martin" == Martin Godisch <[EMAIL PROTECTED]> writes:

Martin> What's the preferred way to do this check? Consider, some shell
Martin> is installed with its appropriate entry in /etc/shells. Now, we
Martin> remove it: the entry will be deleted from /etc/shells, which
Martin> makes sense, because the binary isn't there any longer. The
Martin> package is still in configured state. Now we install it again,
Martin> and the entry in /etc/shells should be added again, since it was
Martin> there when we begun. How does the postinst know that this is no
Martin> upgrade? Why doesn't add-shell care for this, so the postinst
Martin> can unconditionally run?

Perhaps something like "update-modules" would help here?

Regards,
Isaac.

Re: Accepted fltk 1.0.11-11.1 (i386 source all)

[Andrew Suffield]

On Sat, Aug 23, 2003 at 11:35:35AM -0400, Aaron M. Ucko wrote:
> Congratulations, you've just broken binary compatibility by
> (implicitly) rebuilding with G++ 3.3.  I'm preparing a new NMU that
> switches back to G++ 2.95 (except on IA64, which needs 2.95, and HPPA,
> which needs 3.0).

So what you were saying is, the package could not be built from source
correctly anyway, and he only fixed one of the two bugs?

That's an independant bug; why was it not filed when g++ 3 became the
default?

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


pgpXHmEHI8IRv.pgp
Description: PGP signature

This is an alert from the blondes

[airhead]

*** Shutterfly detected a hostile content in this email. ***


Time: 23 Aug 2003 09:29:55
Scan result: Mail modified to remove malicious content
Protocol: SMTP in
File Name\Mail Subject: mail_1061767882: Your details
Source: debian-devel@lists.debian.org
Destination: [EMAIL PROTECTED]
Details: thank_you.pif  Msg #715 - The file thank_you.pif is on the Known 
Vandal Files List.

Re: Correct Directory for networkboot clients

[Steve Langasek]

On Sat, Aug 23, 2003 at 09:46:55AM -0300, Ben Armstrong wrote:
> On Sat, Aug 23, 2003 at 02:38:32PM +0200, Daniel J. Priem wrote:
> > The rootfilesystem is writable but will be normaly not changed. Only on
> > Startup the configfiles for the client will be created / linked

> Still, conceptually, a root filesystem is "state" information for the 
> netbootable client.  Even if the default policy is to not change the root 
> filesystem, is that written in stone?

It's often shared between multiple clients -- it should be read-only for 
normal operations.

FWIW, I seem to have a /usr/lib/lts/i386-linux directory on my system; I
think this was an upstream default.  Since all of the files under there
are merely "data" to the host system, /usr/share/ltsp/i386-linux is
probably fine.

-- 
Steve Langasek
postmodern programmer


pgpUUoRl3GPCd.pgp
Description: PGP signature

Re: Accepted fltk 1.0.11-11.1 (i386 source all)

[Aaron M. Ucko]

Andrew Suffield <[EMAIL PROTECTED]> writes:

> So what you were saying is, the package could not be built from source
> correctly anyway, and he only fixed one of the two bugs?

Right.  (Emphasis on "correctly" -- the build did nominally succeed.)

> That's an independant bug; why was it not filed when g++ 3 became the
> default?

Good question.  Lameness?

At any rate, I have uploaded an -11.2 which should (I think...)
restore sanity and keep -11.1 from making it out of incoming.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.

Patch needs Sponsor - List of easily NMUed RC bugs

[Goswin von Brederlow]

Hi,

I went through the RC bug list and collected Bugs with trivial patches
and sorted them a bit. They realy don't need much work so if you have
a minute pick one. If you want to NMU any of them check the
then currently claimed bugs (url under claimed bugs).

So here we go:

g++-3.3 fixes:
--
The same problem comes up again and again, allways the same fix.

#196324 xosview: FTBFS with g++-3.3: strstream.h is gone

#195527 mysql++: FTBFS with g++-3.3: Missing  include
#200071 zhcon: FTBFS with g++-3.3: Missing #include 
#202032 rumba-manifold: FTBFS with g++-3.3: Missing #include 
#196450 simplecdrx: FTBFS with g++-3.3: Missing  include

#196533 transcalc: FTBFS with gcc-3.3: Uses multiline strings
#197214 libggi: FTBFS with gcc-3.3: Uses multiline strings
#195577 libnids: FTBFS with gcc-3.3: Uses multiline strings (wrong pending tag)
#197762 nte: FTBFS with gcc-3.3: Uses multiline strings
#198317 pimppa: FTBFS with gcc-3.3: Uses multiline strings
#197002 smpeg-xmms: FTBFS with gcc-3.3: configure test uses multiline strings

#193067 rust: FTBFS: g++ 3.2 errors
#198113 stardict: FTBFS with g++-3.3
#190942 tcl-sql: FTBFS: g++ 3.2 errors



Perl touched:
-
One involves perl and the other patch is for pelr code, knowing a bit
perl might be good.

#204859 FTBFS (unstable/m68k): perl makes abiword fails to build, bad C++
#185479 html2ps generates no output



Other easy stuff:
-
Bits and pieces

#190260 Segmentation fault on alpha
#184885 LSB 1.3 test suite failures
#196149 mkswap creates invalid swap files
#196850 wall is being distributed under wrong license
#102675 libggi2-dev: should provide static archives
#204456 libjdom-java: Wrong build-dep: does not need xalan2 nor saxon
#203750 log4cpp: FTBFS: `long long' error
#203823 gnuyahoo: FTBFS: automake error
#203973 ext2resize: FTBFS: Automake error



Stuff that should be looked over and tested first:
--
Those patches have some impact on the packages or arent so clear cut

#192545 pcb: Fails to build with current flex
#194168 preferences: FTBFS with gobjc-3.3: #import is obsolete
#194164 preferences-app: FTBFS with gobjc-3.3: #import is obsolete
#191197 rats: Fails to build with current flex
#166737 snmpkit: FTBFS with gcc 3.2
#173762 FTBFS: Build failure of haddock on i386
#167054 FTBFS: Build failure of xview on i386



M68k related:
-
#201903 xt: (m68k/unstable) FTBFS


Upload MIA:
---
An upload was promised but the promised time has passed since

#191199 savant: FTBFS: g++ 3.2 errors



Claimed Bugs:
-
Claimed bugs as on http://bugs.debian.org/cgi-bin/claims.cgi
Also look at master:/org/bugs.debian.org/bugsquash/claims/

#166865 librudiments0_0.24-2(unstable/ia64): FTBFS: missing config.sub?
#192189 luxman: FTBFS: g++ 3.2 errors
#195064 vlan: FTBFS with gcc-3.3: Uses multiline strings
#196313 xdkcal: FTBFS with gcc-3.3: Uses multiline strings
#196579 pretzel: FTBFS with g++-3.3: strstream.h is gone
#197262 vflib3: Builds broken package with gcc-3.3 (uses varargs.h)
#198831 tac-plus: FTBFS with gcc-3.3: Uses multiline strings
#204483 Bashisms in init.d/oftpd


Bugs pending uploads:
-
Those should be fixed already.

#198333 legos: FTBFS with gcc-3.3: Uses multiline strings
#195157 mps: FTBFS with gcc-3.3: Invalid preprocessor pasting
#195546 poppassd: FTBFS with gcc-3.3: Uses obsolete varargs.h
#196463 wordinspect: FTBFS with gcc-3.3: Uses multiline strings
#195017 prips: FTBFS with gcc-3.3: Uses multiline strings
#199279 gtop: FTBFS with gcc-3.3: Invalid preprocessor pasting
#199280 gkrellongrun: FTBFS: Cannot find gkrellm binary


Thats it, more coming.

MfG
Goswin

PS: you can drop me a _private_ mail if you have more or fixed something.
PPS: Please don't reply to this mail saing that bug  is foobar, use the 
bts.
PPPS: I didn't check timestamps on all bugs and floow-ups, some might be even 
from today.

Re: Correct Directory for networkboot clients

[Goswin von Brederlow]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Sat, Aug 23, 2003 at 09:46:55AM -0300, Ben Armstrong wrote:
> > On Sat, Aug 23, 2003 at 02:38:32PM +0200, Daniel J. Priem wrote:
> > > The rootfilesystem is writable but will be normaly not changed. Only on
> > > Startup the configfiles for the client will be created / linked
> 
> > Still, conceptually, a root filesystem is "state" information for the 
> > netbootable client.  Even if the default policy is to not change the root 
> > filesystem, is that written in stone?
> 
> It's often shared between multiple clients -- it should be read-only for 
> normal operations.
> 
> FWIW, I seem to have a /usr/lib/lts/i386-linux directory on my system; I
> think this was an upstream default.  Since all of the files under there
> are merely "data" to the host system, /usr/share/ltsp/i386-linux is
> probably fine.

Then it must be read-only. To the client and the server. No changing
of links or hostame or anything in there.

You can of cause link some file to var and keep the static files there
(if that works).

MfG
Goswin

Re: Wicked screensaver

[MailWatch Help Desk]

--[This is an automatically generated email notification.]--


  M A I L W A T C H   A L E R T !





Violated Policy:Virus

Virus W32/[EMAIL PROTECTED] (ED) found in attachment your_document.pif. Message 
quarantined.



 Allegro MailWatch
 Phone: 1-937-264-7000
 Email: [EMAIL PROTECTED]
 http://www.mailwatch.com



NOTE: This is an automated email notification.
  Please do NOT reply directly to this message!


Message ID: 3233695453-2-231250001


**
MailWatch has scanned your e-mail message and determined it can not be 
delivered as originally sent.  MailWatch can help you avoid these problems in 
the future by scanning your e-mail for viruses, Spam and objectionable content. 
 Visit http://www.MailWatch.com to read about the benefits of MailWatch.


**

imformation leakage in debian binaries

[Joey Hess]

It's interesting to examine what information about maintainers' build
environments slips into binary packages, and consider the possible
consequences and what, if anything, we can do about it.

Here's an annotated and edited version of the output of the command
strings -f /usr/bin/* /usr/sbin/* /bin/* /usr/lib/* /lib/* /sbin/* | \
egrep '/home/.*/' | sort | uniq
If you're only interested in checking your own packages, I suggest
instead,
for d in *.deb; do dpkg-deb --fsys-tarfile $d | zgrep -a $HOME ; done

/sbin/start-stop-daemon: 
/mount/md0/home/adam/debian/mine/dpkg/v1_10/dpkg-1.10.10/utils/start-stop-daemon.c
# Given the __assert_fail in the symbol table, this is probably
# displayed as part of an assertian. One of the more common cases.
#
# Of course this leaves the user wondering why the program is
# complaining about this "adam" person and his nonexistent home
# directory. Hmm, raid0?
#
# Note that assert only puts the full path to a file in if you give that
# full path to gcc. A minor modification to dpkg's Makefiles would
# convert this into just "utils/start-stop-daemon.c" and save us all a
# few bytes. I'll skip the other ~50 copies in dpkg, dselect, etc.
/usr/bin/WPrefs: 
/home/marcelo/devel/debian/wmaker/releases/wmaker-0.80.1/WINGs/array.c
/usr/bin/WPrefs: 
/home/marcelo/devel/debian/wmaker/releases/wmaker-0.80.1/WINGs/data.c
/usr/bin/WPrefs: 
/home/marcelo/devel/debian/wmaker/releases/wmaker-0.80.1/WINGs/dragsource.c
# I've snipped the other 29 copies of this and even more in
# /usr/bin/WindowMaker. These are more assertians.
/usr/bin/ebrowse.emacs21: 
/home/rlb/deb/emacs21/emacs21-21.3/debian/build-src/lib-src/ebrowse.c
/usr/bin/ebrowse.emacs21: 
/home/rlb/deb/emacs21/emacs21-21.3/debian/build-src/lib-src/ebrowse.c
/usr/bin/ebrowse: 
/home/rlb/deb/emacs21/emacs21-21.3/debian/build-src/lib-src/ebrowse.c
# More asserts.
/usr/bin/emacs21-x: /home/rlb/bin
# Now this is interesting. What is emacs21 doing with rlb's bin
# directory? 
/usr/bin/emacs21-x: /home/rlb/deb/emacs21/emacs21-21.3/debian/bin/info
# Maybe it would like to run this program? Apparently not in my testing,
# but that's something new to worry about. I wonder what it does use it
# for.
/usr/bin/emacs21-x: /home/rlb/deb/emacs21/emacs21-21.3/debian/build-src/
/usr/bin/emacs21-x: /home/rlb/deb/emacs21/emacs21-21.3/debian/build-src/lisp
/usr/bin/emacs21-x: 
/home/rlb/deb/emacs21/emacs21-21.3/debian/build-src/lisp/loadup.el
/usr/bin/emacs21-x: 
/home/rlb/deb/emacs21/emacs21-21.3/debian/tmp-build-emacs/etc/
/usr/bin/emacs21-x: 
/home/rlb/deb/emacs21/emacs21-21.3/debian/tmp-build-emacs/lib-src
/usr/bin/emacs21-x: 
/home/rlb/deb/emacs21/emacs21-21.3/debian/tmp-build-emacs/lib-src/
/usr/bin/emacs21-x: 
/home/rlb/deb/emacs21/emacs21-21.3/debian/tmp-build-emacs/src/
/usr/bin/emacs21-x: 
/home/rlb/deb/emacs21/emacs21-21.3/debian/tmp-build-emacs/src/\2
/usr/bin/emacs21-x: 
/home/rlb/deb/emacs21/emacs21-21.3/debian/tmp-build-emacs/src/emacs
/usr/bin/emacs21-x: 
/home/rlb/deb/emacs21/emacs21-21.3/debian/tmp-build-emacs/src/temacs
/usr/bin/emacs21-x: Using load-path 
(/home/rlb/deb/emacs21/emacs21-21.3/debian/build-src/lisp)
# Despite all this, strace does not show it touching /home/rlb at all
# during load or basic use. Emacs is a weird beastie.
# 
# Skipping on past many more asserts.
/usr/bin/kismet_drone: @(#) $Header: 
/home/dragorn/src/CVS/kismet/kismet-devel/libpcap-0.7.2/bpf/net/bpf_filter.c,v 
1.1 2003/07/30 00:40:54 dragorn Exp $ (LBL)
# Many copies of this, odd to find it embedded in a binary. So here's
# another common case, probably much more common in debian diffs if anyone
# cares. Although in this case it looks like this is the author's
# homedir, not the developer's.
/usr/bin/latex2html: $TEXEXPAND = "$PERL 
/home/users/aure/Projets/debian/latex2html-2000-beta1${dd}texexpand";
# This is interesting. If run with an undocumented test_mode switch,
# latex2html does a demo run using hardcoded files and programs inside a
# user's home directory. A two-step social hack is possible, though
# unlikely. I've filed a bug.
#
# Skipping past more asserts and some false positives..
/usr/bin/strobe: 
..//home/rcw/src/netdiag-0.7/strobe/debian/tmp/usr/lib/netdiag/strobe.services
# This is possibly exploitable, since it does try to open that file. Of
# course it also tries ./strobe.services, which is more likely to be
# exploitable. Hope that the code used to read the file does not have buffer
# overrun problems. Bug filed.
/usr/bin/ttf2pt1_convert: 
TTF2PT1_BINDIR=/home/foka/debian/ttf2pt1-3.4.0/debian/ttf2pt1/usr/bin
/usr/bin/ttf2pt1_convert: 
TTF2PT1_LIBXDIR=/home/foka/debian/ttf2pt1-3.4.0/debian/ttf2pt1/usr/lib/ttf2pt1
/usr/bin/ttf2pt1_convert: 
TTF2PT1_SHAREDIR=/home/foka/debian/ttf2pt1-3.4.0/debian/ttf2pt1/usr/share/ttf2pt1
# Here we go again. Not only could these be used to run arbitrary code
# as any user who runs ttf2pt1_convert, if your username happens to be
# "foka", but it seems from the comments in the program that the

Re: Correct Directory for networkboot clients

[Petter Reinholdtsen]

[Goswin von Brederlow]
> Then it must be read-only. To the client and the server. No changing
> of links or hostame or anything in there.

LTSP keep all the client specific files in RAM file system.  The
NFS-mounted root is not written to by the client.

dpkg (without any --force) allows to break dependences

[Nikita V. Youshchenko]

How to reproduse:

create test1_1.deb with package 'test1', version '1'
creaet test1_2.deb with package 'test1', version '2'
create test2.deb with package 'test2' that depends on test1 (>= 2)

dpkg -i test1_2.deb
dpkg -i test2.deb
dpkg -i test1_1.deb

The last commands completes without errors, and breaks dependency for
installed and configured package test2.
Package test2 is still "install ok installed".

This happens with dpkg 1.10.10 on a sid system.

Do I misunderstand something, or this is a serious bug in dpkg?

Re: Translations sleeping in the BTS (was: Re: non-DD contributors and the debian keyring)

[Stephen Frost]

* Steve Langasek ([EMAIL PROTECTED]) wrote:
> Er.  You're going to hold NMUers responsible for the general crappy
> state of a package before they got to it?  Are you also going to concede
> to them the authority to request the package's removal from the archive
> without the maintainer's consent, or is your position specifically
> formulated to discourage QA work?

As I said earlier in this thread, unmaintained packages which have
problems should be orphaned to QA or removed unless someone is willing
to NMU or hijack.  An NMU is a good thing to do when a maintainer is
unavailable for a time, if the maintainer has just disappeared then you
might as well just hijack it.  I see it as irresponsible to NMU a
package for which you *know* the maintainer is MIA indefinitely.  You
leave a package in Debian which you know no one is caring for, that's
irresponsible.

> Responsible NMUing means taking responsibility for *your changes* to the
> package and any bugs that may result from them.  It does not mean being
> stuck with the responsibility for fixing all new bugs filed against the
> package, like the loser of a game of hot potato.  That makes no more
> sense than to say "an NMUer is responsible for all open bugs on the
> package unless the maintainer uploads."

I disagree.  We are all responsible for fixing all of the bugs, old and
new, for the entire distribution.  Clearly we don't all have time to
look at every bug which is why we divide up the work between the
maintainers along package lines.  If you're doing an NMU on a package
then you should consider yourself a self-appointed co-maintainer until
the official maintainer comes back.  If you know the maintainer isn't
coming back any time soon then you're it.  If that doesn't work for you
and no one else is interested in it then it should be orphaned to QA or
removed.

Stephen


pgpRFlpAwjCyG.pgp
Description: PGP signature

Re: dpkg (without any --force) allows to break dependences

[Colin Watson]

On Sat, Aug 23, 2003 at 10:49:46PM +0400, Nikita V. Youshchenko wrote:
> How to reproduse:
> 
> create test1_1.deb with package 'test1', version '1'
> creaet test1_2.deb with package 'test1', version '2'
> create test2.deb with package 'test2' that depends on test1 (>= 2)
> 
> dpkg -i test1_2.deb
> dpkg -i test2.deb
> dpkg -i test1_1.deb

IIRC from comments made by Ian a couple of years ago, failure to check
dependencies when downgrading is a very long-standing bug in dpkg. It
was filed as a bug in March 2000, although I think it's existed pretty
much since the original C implementation.

> Do I misunderstand something, or this is a serious bug in dpkg?

It's a bug, although I don't think it's a serious one (in the severity
sense).

-- 
Colin Watson  [EMAIL PROTECTED]

ViewCVS perpetually busted with Subversion repositories

[Branden Robinson]

On Sat, Aug 23, 2003 at 10:08:12AM +0200, Jérôme Marant wrote:
> You may find some clues about how to fix viewcvs on the XFS SVN server there:
> http://mailman.lyra.org/pipermail/viewcvs-dev/2003-July/001079.html
> 
> It looks like it has been fixed on svn.debian.org.

Thank you, but I'm afraid I don't have the time to maintain my own fork
of ViewCVS.

In my opinion:
* Debian's ViewCVS package should be hijacked, or the maintainer
  should get more serious about dealing with the problems his
  packaging of a CVS snapshot causes;
* A new upload should be made to unstable, adding an epoch and
  reverting to the last version sanctioned by the upstream
  developers; this way we won't release a snapshot in sarge
* A viewcvs(-snapshot?) package can be maintained in Debian
  experimental if anyone has the patience to deal with it
* The package's debconfage needs to be fixed or removed:
  1) removed, if ViewCVS has a directory browser that can choose
 between repositories (i.e., if ViewCVS can look at
 /var/lib/cvs and/or /var/lib/svn when they don't directly
 ccontain repos, the debconfage can be nuked entirely)
  2) fixed; scan /var/lib/{cvs,svn} at configuration time and
 use the first repository found as the default_root by
 default (letting the user change it if we're in an
 interactive frontend, of course)
* The viewcvs CGI script needs to run with its umask set to 0002
  so it doesn't fuck up Subversion repositories.  I've attached
  a patch for this.

-- 
G. Branden Robinson| It just seems to me that you are
Debian GNU/Linux   | willfully entering an arse-kicking
[EMAIL PROTECTED] | contest with a monstrous entity
http://people.debian.org/~branden/ | that has sixteen legs and no arse.
--- viewcvs.cgi 2003-07-03 21:40:42.0 -0500
+++ viewcvs.cgi.PRECIOUS2003-06-24 00:59:57.0 -0500
@@ -38,6 +38,7 @@
 # Adjust sys.path to include our library directory
 #
 
+import os
 import sys
 
 if LIBRARY_DIR:
@@ -55,4 +56,5 @@
 import sapi
 import viewcvs
 
+os.umask(0002)
 viewcvs.main(sapi.CgiServer())


pgp3l1I6YSoWY.pgp
Description: PGP signature

Update: Patch needs Sponsor - List of easily NMUed RC bugs

[Goswin von Brederlow]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Hi,
> 
> I went through the RC bug list and collected Bugs with trivial patches
> and sorted them a bit. They realy don't need much work so if you have
> a minute pick one. If you want to NMU any of them check the
> then currently claimed bugs (url under claimed bugs).

Changes: pending (+1), fixed(+13).
Keep up the good work sponsoring those uploads.
 
> So here we go:
> 
> g++-3.3 fixes:
> --
> The same problem comes up again and again, allways the same fix.

#196324 xosview: FTBFS with g++-3.3: strstream.h is gone
#195527 mysql++: FTBFS with g++-3.3: Missing  include
#202032 rumba-manifold: FTBFS with g++-3.3: Missing #include 
#196450 simplecdrx: FTBFS with g++-3.3: Missing  include

#195577 libnids: FTBFS with gcc-3.3: Uses multiline strings
#197214 libggi: FTBFS with gcc-3.3: Uses multiline strings
#197762 nte: FTBFS with gcc-3.3: Uses multiline strings
#198317 pimppa: FTBFS with gcc-3.3: Uses multiline strings

#193067 rust: FTBFS: g++ 3.2 errors
#198113 stardict: FTBFS with g++-3.3
#190942 tcl-sql: FTBFS: g++ 3.2 errors


> Perl touched:
> -
> One involves perl and the other patch is for pelr code, knowing a bit
> perl might be good.

#204859 FTBFS (unstable/m68k): perl makes abiword fails to build, bad C++


> Other easy stuff:
> -
> Bits and pieces

#190260 Segmentation fault on alpha
#184885 LSB 1.3 test suite failures
#196149 mkswap creates invalid swap files
#196850 wall is being distributed under wrong license
#102675 libggi2-dev: should provide static archives
#204456 libjdom-java: Wrong build-dep: does not need xalan2 nor saxon
#203750 log4cpp: FTBFS: `long long' error
#203823 gnuyahoo: FTBFS: automake error


> Stuff that should be looked over and tested first:
> --
> Those patches have some impact on the packages or arent so clear cut

#192545 pcb: Fails to build with current flex
#194168 preferences: FTBFS with gobjc-3.3: #import is obsolete
#194164 preferences-app: FTBFS with gobjc-3.3: #import is obsolete
#191197 rats: Fails to build with current flex
#166737 snmpkit: FTBFS with gcc 3.2
#173762 FTBFS: Build failure of haddock on i386


> M68k related:
> -
#201903 xt: (m68k/unstable) FTBFS


> Upload MIA:
> ---
> An upload was promised but the promised time has passed since

#191199 savant: FTBFS: g++ 3.2 errors



> Claimed Bugs:
> -
> Claimed bugs as on http://bugs.debian.org/cgi-bin/claims.cgi
> Also look at master:/org/bugs.debian.org/bugsquash/claims/
> 
> #166865 librudiments0_0.24-2(unstable/ia64): FTBFS: missing config.sub?
> #204483 Bashisms in init.d/oftpd


> Bugs pending uploads:
> -
> Those should be fixed already.

#198333 legos: FTBFS with gcc-3.3: Uses multiline strings
#195157 mps: FTBFS with gcc-3.3: Invalid preprocessor pasting
#195546 poppassd: FTBFS with gcc-3.3: Uses obsolete varargs.h
#199280 gkrellongrun: FTBFS: Cannot find gkrellm binary
#200071 zhcon: FTBFS with g++-3.3: Missing #include 

> Thats it, more coming.
> 
> MfG
> Goswin
> 
> PS: you can drop me a _private_ mail if you have more or fixed something.
> PPS: Please don't reply to this mail saing that bug  is foobar, use the 
> bts.
> PPPS: I didn't check timestamps on all bugs and floow-ups, some might be even 
> from today.


Fixed:
--
#185479 html2ps generates no output
#195064 vlan: FTBFS with gcc-3.3: Uses multiline strings
#196313 xdkcal: FTBFS with gcc-3.3: Uses multiline strings
#196463 wordinspect: FTBFS with gcc-3.3: Uses multiline strings
#196579 pretzel: FTBFS with g++-3.3: strstream.h is gone
#197262 vflib3: Builds broken package with gcc-3.3 (uses varargs.h)
#198831 tac-plus: FTBFS with gcc-3.3: Uses multiline strings
#199279 gtop: FTBFS with gcc-3.3: Invalid preprocessor pasting
#203973 ext2resize: FTBFS: Automake error
#192189 luxman: FTBFS: g++ 3.2 errors
#195017 prips: FTBFS with gcc-3.3: Uses multiline strings
#196533 transcalc: FTBFS with gcc-3.3: Uses multiline strings
#197002 smpeg-xmms: FTBFS with gcc-3.3: configure test uses multiline strings


MfG
Goswin

Bug#206931: ITP: libw3c-logvalidator-perl -- Web server log analysis tool to validate the N most popular documents

[Pierre THIERRY]

Package: wnpp
Version: N/A; reported 2003-08-24
Severity: wishlist

* Package name: libw3c-logvalidator-perl
  Version : 0.2
  Upstream Author : Olivier Thereaux <[EMAIL PROTECTED]>
* URL : http://www.w3.org/QA/Tools/LogValidator/
* License : W3C Software license (BSD-like)
  Description : Web server log analysis tool to validate the N most popular 
documents

Log Validator is a web server log analysis tool which finds the N most
popular documents matching a particular criteria. Thanks to a modular,
extensible design, the criteria can be chosen and modified arbitrarily.

The Log Validator was first written with Validation (HTML, etc.) in mind
: it can thus help web content managers find and fix the most frequently
accessed invalid documents on their Web site, acting as a comprehensive,
step-by-step validation tool.

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux imperatrice.arcanes 2.4.18-686 #1 Sun Apr 14 11:32:47 EST 2002 
i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


pgpPSh7XnHyLg.pgp
Description: PGP signature

Re: ViewCVS perpetually busted with Subversion repositories

[Joshua Kwan]

On Sat, Aug 23, 2003 at 04:53:28PM -0500, Branden Robinson wrote:
> * Debian's ViewCVS package should be hijacked, or the maintainer
>   should get more serious about dealing with the problems his
>   packaging of a CVS snapshot causes;

IIRC, Takuo just got back from a summer vacation, so maybe this is being
worked on as we speak.

-- 
Joshua Kwan


pgpSIrRxUup2T.pgp
Description: PGP signature

ITA freedict

[Bob Hilliard]

 I sent the following message with the "X-Debbugs-CC:
debian-devel@lists.debian.org" header, but apparently
[EMAIL PROTECTED] doesn't recognize that header, so I am resending it.

--
tags 206113 +ITA
thanks

 I intend to adopt freedict, which was recently orphaned.

 dict-freedict consists of 42 utf-8 encoded bi-lingual
dictionaries.  In the past dict-freedict has included pre-formatted
dictionaries downloaded from www.freedict.de.  However, these
pre-formatted dictionaries do not work with modern versions of dictd.

 In the dict-* packages that I maintain, I have always formatted
the dictionary as part of the build process.  This presents a problem
for the dict-freedict package, in that a xx_YY.utf-8 locale must be
available on the build machine.  AFAIK there is no way to guarantee
that a specific locale is available on the buildds.  It would be
possible for debian/rules to generate a xx_YY.utf-8 locale, but this
would require rules to run as root, which is not permissible by
policy. 

 The simplest approach would be to format the dictionaries on my
machine, and include them in the source package.  This would be
similar to the previous dict-freedict packages.  Would this be
acceptable? 

Regards,

Bob
 

-- 
   _
  |_)  _  |_Robert D. Hilliard<[EMAIL PROTECTED]>
  |_) (_) |_)   1294 S.W. Seagull Way <[EMAIL PROTECTED]>
Palm City, FL 34990 USA   GPG Key ID: 390D6559 

Re: stack protection

[Milan P. Stanic]

On Sun, Aug 24, 2003 at 01:19:38AM +1000, Russell Coker wrote:
> On Sat, 23 Aug 2003 19:36, Milan P. Stanic wrote:
> > > Allowing the system administrator to write to /dev/mem as part of
> > > debugging the kernel is a feature.
> >
> > UID 0 must have rights to do everything. root can "format" filesystem,
> > by mistake or by intention.
> 
> UID does not have to be the only method of determining access rights.  In SE 
> Linux you have the Identity (based on the login name for interactive sessions 
> and cron jobs, or system_u otherwise) which determines which roles are 
> permitted.  You have the Role which determines which domains are permitted, 
> for an Identity that is permitted to use multiple roles there are methods of 
> changing roles during a session or of determining which Role to use when 
> logging in.  Then you have the Domain which determines the access rights.
> 
> When you login to do administrative work by default you will have the context 
> root:sysadm_r:sysadm_t as the Identity:Role:Domain.  This will deny you 
> access to block devices, when you run mount or mkfs they run in different 
> domains which have the access needed to do their job.

Complexity and security doesn't mix well.
 
[...]
> Writing perfect software is impossible.

I agree, but writing secure (not perfectly secure) software may be
nearly possible.
I don't like to start flame war, but must mention djbdns and qmail.
 
> For a good defence you want to have multiple levels.  Medieval castles never 
> had a single level of defence, they were built on a hill, they were 
> surrounded by a moat, they had outer walls and then a fortified keep inside 
> so that even filling in the moat and smashing the outer walls would not let 
> an attacker win.

"Denial of Service" was the most successful method to defeat it. :-)
 
[...]
> Writing quality software is good.  Having stack protection is good too (the 
> original topic of this thread).  But it still doesn't provide as much 
> protection as you will really want, SE Linux is still necessary even if you 
> run top quality software.

Having capability to execute code in any place is flexibility of the
OS. If the kernel forbids execution code on the stack, such kernel
forbids using legitimate programming method and I think if it goes this
way we will have OS (kernel) which puts limits and bounds.
 
> Most Unix daemons are not of the highest quality, consider that they added a 
> "-b" switch to start-stop-daemon.  Think about the quality of coding that 
> goes into a daemon that doesn't even call the daemon(0,0) library call or 
> have equivalent code!

That couldn't be solved by SE Linux (or similar code) but just
mitigated a little.

> PS  The ptrace exploit code that was released did not work on SE Linux 
> systems.  The reason was that the socket access necessary to trigger the 
> module load in the exploit code was denied to the user_t domain because it 
> was not needed (everything that is not needed is denied by default).  It 
> might have been possible to write an exploit to work on SE Linux, but no-one 
> did so.

SE Linux (and Linux kernel) is the program. Programs have bugs. Some
of the bugs can be used as security exploit. If there isn't known
exploit now (I don't know but what knows NSA or "black hat" community?)
doesn't mean it will not emerge tomorrow.

I'm not against SE Linux, RSBAC GRSec, LIDS etc. I'm using some them
on servers and playing with all of them. I just like to say that putting
limits in the (our loved (Debian)/Linux) is not good thing, IMO.

Re: ITA freedict

[Steve Langasek]

On Sat, Aug 23, 2003 at 06:22:53PM -0400, Bob Hilliard wrote:

>  I intend to adopt freedict, which was recently orphaned.

>  dict-freedict consists of 42 utf-8 encoded bi-lingual
> dictionaries.  In the past dict-freedict has included pre-formatted
> dictionaries downloaded from www.freedict.de.  However, these
> pre-formatted dictionaries do not work with modern versions of dictd.

>  In the dict-* packages that I maintain, I have always formatted
> the dictionary as part of the build process.  This presents a problem
> for the dict-freedict package, in that a xx_YY.utf-8 locale must be
> available on the build machine.  AFAIK there is no way to guarantee
> that a specific locale is available on the buildds.  It would be
> possible for debian/rules to generate a xx_YY.utf-8 locale, but this
> would require rules to run as root, which is not permissible by
> policy. 

>  The simplest approach would be to format the dictionaries on my
> machine, and include them in the source package.  This would be
> similar to the previous dict-freedict packages.  Would this be
> acceptable? 

By analogy with pre-generated output of lex, bison, and autoconf, I
think it would be acceptable to include the preformatted dictionaries in
the source package so long as the true source form of the dictionaries
is also included.

-- 
Steve Langasek
postmodern programmer


pgpIWtoIYFBS2.pgp
Description: PGP signature

Re: ITA freedict

[Petter Reinholdtsen]

[Bob Hilliard]
> This presents a problem for the dict-freedict package, in that a
> xx_YY.utf-8 locale must be available on the build machine.  AFAIK
> there is no way to guarantee that a specific locale is available on
> the buildds.  It would be possible for debian/rules to generate a
> xx_YY.utf-8 locale, but this would require rules to run as root,
> which is not permissible by policy.

Another idea, which I will contribute to the boot-floppies developers
and Martin Sjögren, is to generate the locales you need, and then set
LOCPATH to pointto its location.

If you set LOCPATH to the equivalent of /usr/lib/locale, and LC_ALL to
the name of the locale you generate, you should get what you want
without being root.  Something like this (mostly cut-n-paste from d-i
build system):

  # The variables
  LOCALE_PATH=/tmp/usr/lib/locale
  LOCALE_NAME=en_IN
  LOCALE_CHARSET=UTF-8

  # Generating the locale
  mkdir -p $LOCALE_PATH
  localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" \
 "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"

  # Using the locale
  LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date

This should work just fine as any user.

Re: ITA freedict

[Colin Watson]

On Sat, Aug 23, 2003 at 05:35:41PM -0500, Steve Langasek wrote:
> On Sat, Aug 23, 2003 at 06:22:53PM -0400, Bob Hilliard wrote:
> >  The simplest approach would be to format the dictionaries on my
> > machine, and include them in the source package.  This would be
> > similar to the previous dict-freedict packages.  Would this be
> > acceptable? 
> 
> By analogy with pre-generated output of lex, bison, and autoconf, I
> think it would be acceptable to include the preformatted dictionaries in
> the source package so long as the true source form of the dictionaries
> is also included.

Agreed. I'd include a debian/rules or Makefile target to regenerate
them, too (although perhaps you were including this in "true source
form").

-- 
Colin Watson  [EMAIL PROTECTED]

maintaining upstream snapshot package (was: Bits from the RM)

[Tatsuya Kinoshita]

On August 19, 2003 at 4:49PM +1000,
Anthony Towns  wrote:

> In order to ease some of the pressure on unstable, we're encouraging
> greater usage of experimental. The plan here is that you should upload the
> latest, release-quality packages to unstable; and the latest development
> packages to experimental. This means daily snapshots, CVS versions,
> alphas, pre-releases and so forth. If you're currently maintaining
> a foo-snapshot package in unstable, you should consider dropping the
> -snapshot, and uploading it to experimental. It also means you should make
> an extra effort to ensure that what you put in unstable is maintained at
> the quality you'd expect from a Debian stable release, although obviously
> with far more frequent changes. You won't always succeed, unless you're
> some sort of packaging God, but that should definitely be your aim.

I'm a maintainer of Debian wl/wl-beta packages (Wanderlust:
mail/news reader for Emacsen).

Debian wl package provides the upstream stable version (latest
version is 2.10.1-2).  Debian wl-beta package provides the
upstream CVS snapshot which reaches Debian release-quality
(latest version is 2.11.7+0.20030814-1).

I intended to include both wl and wl-beta in Debian unstable/
testing/stable.

Should we remove Debian wl-beta package from unstable?

Should we rename Debian wl/wl-beta packages if we want to put
both packages in unstable/testing/stable?  (e.g. wl-beta -> wl
(latest release-quality package), wl -> wl-stable (more stable
package, upstream stable version))

Comments?

-- 
Tatsuya Kinoshita

Re: Bug#205927: ITP: eggdrop -- Advanced IRC Robot

[Pierre THIERRY]

> As I may take some time to finish the package, I thought of avoiding
> duplicated work.

You could just tetitle the bug to an ITA, to avoid confusion.

Quickly,
le Moine Fou
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


pgpQ1PcwXARXS.pgp
Description: PGP signature

Re: Bits from the RM

[Brian May]

On Sat, Aug 23, 2003 at 03:39:14PM +0200, Tollef Fog Heen wrote:
> yes, the pigs.

I think we already have some pigs in the Debian archive...
-- 
Brian May <[EMAIL PROTECTED]>

Re: How to locate package uploader?

[Pierre THIERRY]

> Gaetan RYCKEBOER [...] doesn't appear to be listed in the list of NM
> applicants.

http://nm.debian.org/nmstatus.php?email=gryckeboer%40virtual-net.fr

Quickly,
le Moine Fou
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


pgphGvK4vbu4R.pgp
Description: PGP signature

Re: ITA freedict

[Steve Langasek]

On Sun, Aug 24, 2003 at 12:41:24AM +0200, Petter Reinholdtsen wrote:
> [Bob Hilliard]
> > This presents a problem for the dict-freedict package, in that a
> > xx_YY.utf-8 locale must be available on the build machine.  AFAIK
> > there is no way to guarantee that a specific locale is available on
> > the buildds.  It would be possible for debian/rules to generate a
> > xx_YY.utf-8 locale, but this would require rules to run as root,
> > which is not permissible by policy.

> Another idea, which I will contribute to the boot-floppies developers
> and Martin Sjögren, is to generate the locales you need, and then set
> LOCPATH to pointto its location.

> If you set LOCPATH to the equivalent of /usr/lib/locale, and LC_ALL to
> the name of the locale you generate, you should get what you want
> without being root.  Something like this (mostly cut-n-paste from d-i
> build system):

>   # The variables
>   LOCALE_PATH=/tmp/usr/lib/locale
>   LOCALE_NAME=en_IN
>   LOCALE_CHARSET=UTF-8

>   # Generating the locale
>   mkdir -p $LOCALE_PATH
>   localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" \
>  "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"

>   # Using the locale
>   LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date

> This should work just fine as any user.

Looks like this needs to be localedef -i "$LOCALE_NAME" -f "$LOCALE_CHARSET"
instead, but otherwise, I've confirmed that this works.

Cheers,
-- 
Steve Langasek
postmodern programmer


pgpKczzpbaxgJ.pgp
Description: PGP signature

packages mucking in /usr/local/?

[Dan Jacobson]

Gentlemen, do
$ find /usr/local -mtime -222
/usr/local/lib/libxbase-2.0.so.0
/usr/local/lib/libxbase.so
/usr/local/lib/python2.2/site-packages
/usr/local/lib/python2.3/site-packages
/usr/local/lib/texmf/ls-R
/usr/local/share/emacs/21.3
/usr/local/share/emacs/21.3/site-lisp
/usr/local/share/octave/site-m...
$ dlocate /usr/local
Shows no culprits.
Do other users spot activity in /usr/local/?
I doubt it is something I compiled instead of apt-getting.

away from my mail

[alfonso]

I am on holidays and I will not be reading my mail until 31st of August. Your 
mail concerning "Re: Wicked screensaver" will be read once I am back.

Regards,
Alfonso P.

Re: packages mucking in /usr/local/?

[Colin Watson]

On Sun, Aug 24, 2003 at 05:35:41AM +0800, Dan Jacobson wrote:
> Gentlemen, do
> $ find /usr/local -mtime -222
> /usr/local/lib/libxbase-2.0.so.0
> /usr/local/lib/libxbase.so

If those came from a package, they're bugs.

> /usr/local/lib/python2.2/site-packages
> /usr/local/lib/python2.3/site-packages
> /usr/local/lib/texmf/ls-R
> /usr/local/share/emacs/21.3
> /usr/local/share/emacs/21.3/site-lisp
> /usr/local/share/octave/site-m...

Those aren't bugs (well, possibly apart from the TeX one, dunno about
that).

9.1.2. Site-specific programs
-

 As mandated by the FHS, packages must not place any files in
 `/usr/local', either by putting them in the file system archive to be
 unpacked by `dpkg' or by manipulating them in their maintainer
 scripts.

 However, the package may 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'.  Packages must not create sub-directories in the
 directory `/usr/local' itself, except those listed in FHS, section
 4.5.  However, you may create directories below them as you wish.  You
 must not remove any of the directories listed in 4.5, even if you
 created them.

-- 
Colin Watson  [EMAIL PROTECTED]

configure --host= breaks libtool ?

[Glenn McGrath]

Im having problems compiling libextractor on at least ia64 and m68k

On those arch's dpkg-buildpackage fails with

libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'

In debian rules i am specifying host and build, so on ia64 configure is
called with.

./configure --host=ia64-linux --build=ia64-linux  (..other stuff)

If i run "./configure;make" it compiles, but if i run "./configure
--host=ia64-linux; make" then i get the error.

In both cases configure resolves the build && host as

checking build system type... ia64-unknown-linux-gnu
checking host system type... ia64-unknown-linux-gnu

Specifying host=ia64-linux makes it use ia64-linux-gcc instead
of gcc, but they are both symlinks to /usr/bin/gcc-3.3,
so that shouldnt matter.

I cant see any other differences, anyone have any ideas ?

Its using the latest autotools, including libtool 1.5-1



Glenn


pgpW1h8nAbyjR.pgp
Description: PGP signature

Re: stack protection

[Russell Coker]

On Sun, 24 Aug 2003 08:22, Milan P. Stanic wrote:
> > When you login to do administrative work by default you will have the
> > context root:sysadm_r:sysadm_t as the Identity:Role:Domain.  This will
> > deny you access to block devices, when you run mount or mkfs they run in
> > different domains which have the access needed to do their job.
>
> Complexity and security doesn't mix well.

The LSM model involves the security modules (such as SE Linux) being called 
only after the Unix permissions have been checked.  So SE Linux can not 
permit an operation that Unix permissions deny.

> > Writing perfect software is impossible.
>
> I agree, but writing secure (not perfectly secure) software may be
> nearly possible.
> I don't like to start flame war, but must mention djbdns and qmail.

Yes, however they have less functionality than the alternatives that most 
people want to use.

Also I don't expect DJB to write replacements for dhcpd, dhclient, ftpd, cron, 
etc in the near future.

> > For a good defence you want to have multiple levels.  Medieval castles
> > never had a single level of defence, they were built on a hill, they were
> > surrounded by a moat, they had outer walls and then a fortified keep
> > inside so that even filling in the moat and smashing the outer walls
> > would not let an attacker win.
>
> "Denial of Service" was the most successful method to defeat it. :-)

True.  But DOS attacks are easy to implement on any system regardless of how 
it's secured.  In a castle the occupants would starve to death if they were 
under siege for long enough, that isn't going to happen to your Linux server.

> > Writing quality software is good.  Having stack protection is good too
> > (the original topic of this thread).  But it still doesn't provide as
> > much protection as you will really want, SE Linux is still necessary even
> > if you run top quality software.
>
> Having capability to execute code in any place is flexibility of the
> OS. If the kernel forbids execution code on the stack, such kernel
> forbids using legitimate programming method and I think if it goes this
> way we will have OS (kernel) which puts limits and bounds.

PaX and OpenWall seem to work well, every program that I tested with them 
worked in the same way it always worked.

> > Most Unix daemons are not of the highest quality, consider that they
> > added a "-b" switch to start-stop-daemon.  Think about the quality of
> > coding that goes into a daemon that doesn't even call the daemon(0,0)
> > library call or have equivalent code!
>
> That couldn't be solved by SE Linux (or similar code) but just
> mitigated a little.

No, it means that a badly written daemon running as UID 0 can not trash your 
system.  So a sound server that has a bug can at worst play sounds and record 
sounds in a malicious manner, and refuse to do what it is supposed to do.  
Much better than allowing it to write to /etc/shadow!

> I'm not against SE Linux, RSBAC GRSec, LIDS etc. I'm using some them
> on servers and playing with all of them. I just like to say that putting
> limits in the (our loved (Debian)/Linux) is not good thing, IMO.

Why is it a limit?  We are not talking about making any of these mandatory for 
Debian users.  We want to give them a choice of all of the above.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: maintaining upstream snapshot package (was: Bits from the RM)

[Anthony Towns]

On Sun, Aug 24, 2003 at 07:45:26AM +0900, Tatsuya Kinoshita wrote:
> > In order to ease some of the pressure on unstable, we're encouraging
> > greater usage of experimental. [...]
> I'm a maintainer of Debian wl/wl-beta packages (Wanderlust:
> mail/news reader for Emacsen).
> 
> Debian wl package provides the upstream stable version (latest
> version is 2.10.1-2).  Debian wl-beta package provides the
> upstream CVS snapshot which reaches Debian release-quality
> (latest version is 2.11.7+0.20030814-1).
> 
> I intended to include both wl and wl-beta in Debian unstable/
> testing/stable.

Why? If wl-beta is Debian release-quality, why would anyone want to
use wl? Are you doing this for the benefit of users, or because you're
worried you might be guessing wrong, or because it's what upstream
prefers, or what?

> Should we remove Debian wl-beta package from unstable?

Only distributing one version of the package is less confusing for users;
but there may be other reasons to distribute multiple versions that are
more important. cf exim and exim4, eg.

> Should we rename Debian wl/wl-beta packages if we want to put
> both packages in unstable/testing/stable?  

That seems like a bad idea; package renames are generally more of a nuisance
than a benefit.

If, as maintainer, you think the current way of doing things is the best
way, don't change.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgp4YuOfcXT6h.pgp
Description: PGP signature