[no subject]

[Æ®À©½º]

Re: Bug#149714: libfam0 Does not depend on fam

[sen_ml]

Hi,

From: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Subject: Re: Bug#149714: libfam0 Does not depend on fam
Date: Mon, 19 Aug 2002 08:54:54 -0300

> On Mon, 19 Aug 2002, [EMAIL PROTECTED] wrote:
> > > purposes, defeats the dependencies - or comment it in /etc/inetd.conf,
> > > but AFAIG there is no guarantee that a future upgrade of the fam package
> > > will not reactivate it.

I didn't write the above -- though I think I have been bitten by this
kind of thing for one package in the past.

> File a serious bug on fam if it ever overrides your local configuration
> automatically. This is Not Allowed.

I think the point trying to be made here is not that such a thing
would be done intentionally, but that:

   it might not be too unlikely to happen through error 

   -AND-

   it's in a package that we didn't want to install any way 

   -AND-

   we don't know of a way to easily prevent this package from being
   installed if using dselect [1].

So, if the libfam* packages had to be changed, it would be nice to
have a better way to deal w/ this type of situation.  May be there is
one -- if there is, please let us know!  (-;


[1] Having to use "Q" EVERY time we use dselect to prevent the package
from being installed may eventually lead to pilot error.

Re: OT RE: unsubscribe

[Gareth Bowker]

On Mon, Aug 19, 2002 at 11:24:19PM +0300, Pavel Minev Penev wrote:

> as possible. They allow even ads from time to time (there was a $1000
> fine for commercial messages IIRC, is there still one?)

Still there...

http://www.debian.org/MailingLists/#ads

Gareth

Re: OT RE: unsubscribe

[Pavel Minev Penev]

On Mon, Aug 19, 2002 at 08:41:29PM +0300, Boyan Krosnov wrote:
> > But all in all you can always send these posts to /dev/null 
> > with procmail.
> Why not do it on the mailing list server instead on all those inocent
> recipients? :)

Filtering on a subject basis seems too dangerous to me, and filtering on
a subject + body basis may still let some messages through. Anyway, the
Debain mailing lists are open, non-moderated, delivering mail as quickly
as possible. They allow even ads from time to time (there was a $1000
fine for commercial messages IIRC, is there still one?), so these
"unsubscribe" messages are just peanuts. "Be open to everyone and
everything" is part of the lists's policy, I think.

In today's world of daily (or even hourly) spam and "I can't log into my
Yahoo! account" messages, people have to get used quickly. Then are you
really so concerned with these "unsubscribe" messages that you create
threads on them (at least once a month) in the debian-*security* mailing
list? Or you just like having a chat? Because that is what I am doing
right now.  I don't care about:

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

or about

> starting the next OT flame war on debian lists,

. I care about this:

> Boyan Krosnov, CCIE#8701
> http://boyan.ludost.net/
> Just another techie speaking for himself

HEY, BOBBY!!! I haven't heard from you since I implemeted linked lists
in C macros, or maybe even since I was making the computer synthesize
the sound of puking (am I starting to forget?). A nice place to meet
you -- the security list. A more physical one may feel better, huh? If
you happen to find yourself in one, drop a line, please! You can find me
in the same old place in front of the computer. See you.

To all who read me and not, best whishes and more security,
-- 
Pav

Re: unsubscribe

[Michael Renzmann]

Hi Simon.

Simon Fuhrmann wrote:

[...]
Or am I the only subscriber who receives messages with this footer text: 
[...]

I can calm you, I get this footer too ;-)


Oh, great *phew* :)

Meanwhile the first poster "injected" a really good idea into my mind... 
why not filter away those messages? As the list still will send them, I 
have to do that on my pc. Using procmail this would be easy, but I also 
read my mails on Win2k with Mozilla. I did not think about the fact that 
Mozilla features some very nice mail filter possibilities... now those 
messages won't bug me anymore :))


Bye, Mike

Re: unsubscribe

[Simon Fuhrmann]

Hi!

> [...]
> Or am I the only subscriber who receives messages with this footer text: 
> [...]

I can calm you, I get this footer too ;-)

-- 
Simon Fuhrmann | [EMAIL PROTECTED] | www.dismember.de

GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

OT RE: unsubscribe

[Boyan Krosnov]

> But all in all you can always send these posts to /dev/null 
> with procmail.
Why not do it on the mailing list server instead on all those inocent
recipients? :)

starting the next OT flame war on debian lists,
Boyan Krosnov, CCIE#8701
http://boyan.ludost.net/
Just another techie speaking for himself

Re: unsubscribe

[Grzegorz Kusnierz]

On Mon, Aug 19, 2002 at 07:07:12PM +0200, Michael Renzmann wrote:
> I must be really hard for some people to read the footer lines of every 
> mail they receive over this mailinglist... since I subscribed here to 
> this list (4 days or so) every day at least one of those "unsubscribe" 
> mails have been arriving. Or am I the only subscriber who receives 
> messages with this footer text:
> 
> (...)

Yeah... it's really quite funny :)
But all in all you can always send these posts to /dev/null with procmail.

-- 

Grzegorz "Konik" Kusnierz
<[EMAIL PROTECTED]>

--

Peace, n.:
In international affairs, a period of cheating between two
periods of fighting.
-- Ambrose Bierce, "The Devil's Dictionary"

Re: unsubscribe

[Michael Renzmann]

I must be really hard for some people to read the footer lines of every 
mail they receive over this mailinglist... since I subscribed here to 
this list (4 days or so) every day at least one of those "unsubscribe" 
mails have been arriving. Or am I the only subscriber who receives 
messages with this footer text:


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

One question after another... :)

Bye, Mike

Re: Fwd: @(#) Mordred Labs advisory 0x0001: Buffer overflow in PostgreSQL

[Christoph Moench-Tegeder]

## Phillip Hofmeister ([EMAIL PROTECTED]):

> --[ Solution:
> Upgrade to version 7.2.1.

No need to panic. Woody ist at postgresql-7.2.1-2, and potato might
be too old to have this bug.

Regards,
cmt

-- 
Spare Space

unsubscribe

[Jose Luis Fernandez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9YSKgMH8rk/80JWYRAkChAJ4j32BDMszTBegvFMxtmvwe33xZ8wCfY4dc
TPn4YgsZDWAvdWZ1/GOs1qY=
=2t96
-END PGP SIGNATURE-

Fwd: @(#) Mordred Labs advisory 0x0001: Buffer overflow in PostgreSQL

[Phillip Hofmeister]

I am sure the Security team is already on thisbut an FYI.

- Forwarded message from Sir Mordred The Traitor <[EMAIL PROTECTED]> -

Envelope-to: [EMAIL PROTECTED]
Delivery-date: Mon, 19 Aug 2002 12:35:47 -0400
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Id: 
List-Post: 
List-Help: 
List-Unsubscribe: 
List-Subscribe: 
Delivered-To: mailing list bugtraq@securityfocus.com
Delivered-To: moderator for bugtraq@securityfocus.com
Date: Mon, 19 Aug 2002 15:40:28 +
From: Sir Mordred The Traitor <[EMAIL PROTECTED]>
To: bugtraq@securityfocus.com
Subject: @(#) Mordred Labs advisory 0x0001: Buffer overflow in PostgreSQL

// @(#) Mordred Labs Advisory 0x0001

Release data: 19/08/02
Name: Buffer overflow in PostgreSQL
Versions affected: <= 7.2
Risk: average

--[ Description:
PostgreSQL is an advanced object-relational database management system
that supports an extended subset of the SQL standard, including
transactions,
foreign keys, subqueries, triggers, user-defined types and functions.

There exists a stack based buffer overflow in cash_words() function, that
potentially allows an attacker to execute malicious code.

--[ How to reproduce:
psql> select cash_words('-70');
pgReadData() -- backend closed the channel unexpectedly.
 
The connection to the server was lost...

--[ Solution:
Upgrade to version 7.2.1.





This letter has been delivered unencrypted. We'd like to remind you that
the full protection of e-mail correspondence is provided by S-mail
encryption mechanisms if only both, Sender and Recipient use S-mail.
Register at S-mail.com: http://www.s-mail.com/inf/en

- End forwarded message -

-- 
Phil

PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/ | gpg --import

Re: Bug#149714: libfam0 Does not depend on fam

[Henrique de Moraes Holschuh]

On Mon, 19 Aug 2002, [EMAIL PROTECTED] wrote:
> > purposes, defeats the dependencies - or comment it in /etc/inetd.conf,
> > but AFAIG there is no guarantee that a future upgrade of the fam package
> > will not reactivate it.

File a serious bug on fam if it ever overrides your local configuration
automatically. This is Not Allowed.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: debian-security-announce-$lang@lists?

[Martin Schulze]

Ricardo Javier Cardenes Medina wrote:
> Mmmh... Comes to mind... What are the chances for a non-developer to be
> on "writers" at CVS now that we're authenticating via developer-related
> ssh keys? That would be very convenient just as many people (at least on
> the Spanish team) remain not being Debian Developers themselves, and
> relay on the developers to upload their changes. We've been thinking on
> a quite complicated way involving a second CVS on our servers :-D, but
> it's a lot of burden, if you ask me.

Please read http://www.debian.org/devel/website/

Regards,

Joey

-- 
GNU GPL: "The source will be with you... always."

Please always Cc to me when replying to me on the lists.

unsubscribe

[wizztick]

Re: Bug#149714: libfam0 Does not depend on fam

[sen_ml]

Hi,

From: Cedric Ware <[EMAIL PROTECTED]>
Subject: Re: Bug#149714: libfam0 Does not depend on fam
Date: Sun, 18 Aug 2002 02:30:02 +0200

> I do use dselect and have no use for a local famd, and am somewhat annoyed
> by this change in stable.  (I have a vague recollection that dependencies
> in stable should not change, but I can't find anything about it in policy,
> so I must be mistaken.)

Please add me to the list of annoyed people (-;

> Well, I'm not sure about how not to do it since, as you say, dselect does
> now pester about it.  If famd is not to run locally, one must either use
> 'Q' to tell dselect to really not touch it - which, for all intents and
> purposes, defeats the dependencies - or comment it in /etc/inetd.conf,
> but AFAIG there is no guarantee that a future upgrade of the fam package
> will not reactivate it.
> 
> Or is there a better way?

I'd like to know the answer to this question as well.