Debian Bug report logs - #23661
[REJECTED] /usr/doc should not be accessible through http servers by default

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Martin Stjernholm <mast@lysator.liu.se>

To: submit@bugs.debian.org

Subject: Security issue when accessing documentation through an http server

Date: 18 Jun 1998 01:22:45 +0200

Package: debian-policy
Version: 2.4.1.1
Severity: important

Section 4.4 item 2 in the Debian Policy Manual implies that /usr/doc
should be made accessible by a web server. It's not mentioned there
that it would introduce a security weakness if access to those files
isn't restricted to localhost. Almost every package puts files under
/usr/doc, which, if access is unrestricted, makes it possible for
anyone on the network to do a very detailed scan of the installed
software on the computer, including version information in most cases.
This sort of info is a great help for an attacker to choose an
appropriate method to get into the system.

An example is the dhttpd web server package, which has this problem
(see #23659). I haven't checked the other web server packages.

I suggest the manual be more clear on this, and that it states clearly
that a web server package shouldn't provide access through
http://localhost/doc/ if it can't do it securely.

Moreover, I'm sceptic to the whole concept of providing documentation
access on the standard http port; it's a service much like anonymous
ftp, and as such the user should have complete and explicit control
over the information it provides (well, a harmless example homepage
could be excused). Even though a web server properly restricts access,
it's still a limitation of the namespace available to the user; (s)he
can't use /doc/... in any URL without having to break Debian policy
(at least for local users). I can see two solutions:

1.  Use "file://localhost/usr/doc/" instead. I don't know whether this
    is a strictly valid URL or if it's supported by all browsers, but
    otherwise I believe it's the best solution, since it's both faster
    and works when a web server isn't installed.

2.  Use another port, e.g. "http://localhost:666/usr/doc/". Access
    must be restricted to localhost and the port should be below 1024
    to ensure that no untrusted user on the system can start a web
    server on that port if the admin hasn't done so.

/Martin

Message #10 received at 23661@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joey@kitenet.net>

To: Martin Stjernholm <mast@lysator.liu.se>, 23661@bugs.debian.org

Subject: Re: Bug#23661: Security issue when accessing documentation through an http server

Date: Wed, 17 Jun 1998 20:02:27 -0700

Martin Stjernholm wrote:
> Section 4.4 item 2 in the Debian Policy Manual implies that /usr/doc
> should be made accessible by a web server. It's not mentioned there
> that it would introduce a security weakness if access to those files
> isn't restricted to localhost. Almost every package puts files under
> /usr/doc, which, if access is unrestricted, makes it possible for
> anyone on the network to do a very detailed scan of the installed
> software on the computer, including version information in most cases.
> This sort of info is a great help for an attacker to choose an
> appropriate method to get into the system.

Interestingly, I brought this up when we formulated the policy, and was
informed that I was just worrying about "security through obscurity" and it
wouldn't do any good.

-- 
see shy jo

Message #15 received at 23661@bugs.debian.org (full text, mbox, reply):

From: Martin Stjernholm <mast@lysator.liu.se>

To: 23661@bugs.debian.org

Subject: Re: Bug#23661: Security issue when accessing documentation through an http server

Date: 18 Jun 1998 15:35:08 +0200

Joey Hess <joey@kitenet.net> wrote:

> Martin Stjernholm wrote:
> > Section 4.4 item 2 in the Debian Policy Manual implies that /usr/doc
> > should be made accessible by a web server. It's not mentioned there
> > that it would introduce a security weakness if access to those files
> > isn't restricted to localhost. Almost every package puts files under
> > /usr/doc, which, if access is unrestricted, makes it possible for
> > anyone on the network to do a very detailed scan of the installed
> > software on the computer, including version information in most cases.
> > This sort of info is a great help for an attacker to choose an
> > appropriate method to get into the system.
> 
> Interestingly, I brought this up when we formulated the policy, and was
> informed that I was just worrying about "security through obscurity" and it
> wouldn't do any good.

Strictly speaking, that's true. Otoh, making this info so easily
accessible is sort of like betting that every remotely accessible
piece of software on a Debian system doesn't contain a security
glitch. The loosers in this case are all the users that doesn't keep
an eye on the Debian mirrors, CERT, bugtraq and other forums, because
this makes it very easy to scan a large number of computers for known
vulnerabilities and also hide that traffic in perfectly normal http
accesses.

E.g. if someone scans my subnet on the imap and pop ports, some people
will probably notice and alert the admins to track down this clown. If
(s)he scans on the http port, there's a lot less chance someone will
be reading their access log thoroughly enough to notice that /doc is
accessed. The cracker has got the same information to target
vulnerable systems without stirring things up so much.

I can also imagine scenarios with relatively relaxed firewall
configurations where this would help an attacker to get information
about installed software on computers behind the firewall.

Another thing is that questionable software in the contrib section or
from third parties also is likely to put things under /usr/doc, and
thereby "announce" their presence in a way that's probably unintended
by both the package maintainer and the user.

To conclude, it's obvious that this is a help for a cracker. That
being the case, it's a matter of judgement whether the provided
service outweights the lowered security level. It's my strong belief
that choices like this should be made by the user and not stipulated
by a policy. (And in this case the same service can be provided in a
more secure way, so there's no reason not to do so.)

/Martin

Message #34 received at 23661@bugs.debian.org (full text, mbox, reply):

From: Ian Jackson <ian@davenant.greenend.org.uk>

To: 23661@bugs.debian.org

Subject: /usr/doc should not be accessible through http servers by default

Date: Tue, 21 Mar 2000 23:00:18 +0000 (GMT)

I have just noticed that this bug has been closed.

I can find no explanation for its closure in the BTS.  I'm reopening
it pending discussion.  See my other mails.

I agree with the suggestion, but think it should be widened to rarely
providing any public network services by default.

Ian.

Message #41 received at 23661@bugs.debian.org (full text, mbox, reply):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

To: security@debian.org

Cc: 23661@bugs.debian.org

Subject: Bug#23661: /usr/doc should not be accessible through http servers by default

Date: Tue, 20 Jun 2000 09:58:01 +0100

Here's an issue.  About two years ago there was a proposal that the
default httpd setup should not allow /usr/doc to be remotely
accessible, as it's a huge security risk.  (Yes, we're talking about a
small amount of "security through obscurity" here, but we don't need
to hand crackers this information on a golden plate.)

Nothing appears to have been done about it.

Where do we go from here?  Do we steam ahead and make it policy or
what?  Are there any good reasons why this *shouldn't* be done?

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Message #46 received at 23661@bugs.debian.org (full text, mbox, reply):

From: Marco d'Itri <md@linux.it>

Cc: security@debian.org, 23661@bugs.debian.org

Subject: Re: Bug#23661: /usr/doc should not be accessible through http servers by default

Date: Tue, 20 Jun 2000 13:20:37 +0200

On Jun 20, Julian Gilbey <J.D.Gilbey@qmw.ac.uk> wrote:

 >Where do we go from here?  Do we steam ahead and make it policy or
 >what?
Yes, please.

-- 
ciao,
Marco

Message #51 received at 23661@bugs.debian.org (full text, mbox, reply):

From: Petr Cech <cech@atrey.karlin.mff.cuni.cz>

To: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

Cc: security@debian.org, 23661@bugs.debian.org

Subject: Re: Bug#23661: /usr/doc should not be accessible through http servers by default

Date: Tue, 20 Jun 2000 14:35:45 +0200

On Tue, Jun 20, 2000 at 09:58:01AM +0100 , Julian Gilbey wrote:
> Here's an issue.  About two years ago there was a proposal that the
> default httpd setup should not allow /usr/doc to be remotely
> accessible, as it's a huge security risk.  (Yes, we're talking about a
> small amount of "security through obscurity" here, but we don't need
> to hand crackers this information on a golden plate.)
> 
> Nothing appears to have been done about it.

there was. At least in recent apache
# Debian Policy assumes /usr/doc is "/doc/", at least from the localhost.
# 
<Directory /usr/doc>
Options Indexes FollowSymLinks
AllowOverride None
order deny,allow
deny from all
allow from localhost
</Directory>
 
> Where do we go from here?  Do we steam ahead and make it policy or
> what?  Are there any good reasons why this *shouldn't* be done?
> 
>    Julian

				Petr Cech
-- 
Debian GNU/Linux maintainer - www.debian.{org,cz}
           cech@atrey.karlin.mff.cuni.cz

Those who don't understand Unix are condemned to reinvent it, poorly.

Message #56 received at 23661@bugs.debian.org (full text, mbox, reply):

From: Raul Miller <moth@debian.org>

To: security@debian.org, 23661@bugs.debian.org

Subject: Re: Bug#23661: /usr/doc should not be accessible through http servers by default

Date: Tue, 20 Jun 2000 08:45:25 -0400

On Tue, Jun 20, 2000 at 09:58:01AM +0100, Julian Gilbey wrote:
> Here's an issue.  About two years ago there was a proposal that the
> default httpd setup should not allow /usr/doc to be remotely
> accessible, as it's a huge security risk.  (Yes, we're talking about a
> small amount of "security through obscurity" here, but we don't need
> to hand crackers this information on a golden plate.)
> 
> Nothing appears to have been done about it.
> 
> Where do we go from here?  Do we steam ahead and make it policy or
> what?  Are there any good reasons why this *shouldn't* be done?

In my opinion, this is true of all services.  Exporting them to all
connected systems by default is a security risk.  And, while there's a lot
we could do if the technology were better, we could at least have some
sort of file in /etc which defines some basic policy about such things
-- export by default vs. localhost only vs. ask user vs. export only
"the important stuff" by default [which, unfortnately, is undecidable,
but it's worth mentioning if only for contrast].

I've suggested this earlier, and had ipchains recommended to me.

Unfortunately, ipchains really is inadequate for this purpose -- ipchains
must make decisions based on protocol, ip addr, and ip port -- it doesn't
have the capability to make decisions based on the program(s) involved.
Thus, ipchains is completely useless for rpc, almost useless for udp
[unless you want to turn off dns], and somewhat useless for a system
which must allow non-PASV ftp.

What would be "really nice", of course, would be an enhancement to
ipchains which let you make decisions on a per-program basis.  But,
since we don't have that, I think we need a little more attention on
getting the user involved in the configuration of exported services.

And, of course, ipchains will never solve issues like exporting /usr/doc/
along with /var/www/.

My guess is that debconf could be pressed into service, here.  For woody,
it would be nice to have a whole category of optional questions related to
"do you want this exported or not".  Share some initial leading question
or three, so that people can choose whether they want this level of detail
at config time, and then leave the rest up to package implementation.

-- 
Raul

Message #61 received at 23661@bugs.debian.org (full text, mbox, reply):

From: Steve Robbins <steve@nyongwa.montreal.qc.ca>

To: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>, 23661@bugs.debian.org

Cc: security@debian.org, debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>

Subject: Re: Bug#23661: usr/doc should not be accessible through http servers by default

Date: Tue, 20 Jun 2000 09:13:47 -0400 (EDT)

On Tue, 20 Jun 2000, Julian Gilbey wrote:

> Here's an issue.  About two years ago there was a proposal that the
> default httpd setup should not allow /usr/doc to be remotely
> accessible, as it's a huge security risk.  (Yes, we're talking about a
> small amount of "security through obscurity" here, but we don't need
> to hand crackers this information on a golden plate.)
> 
> Nothing appears to have been done about it.
> 
> Where do we go from here?  Do we steam ahead and make it policy or
> what?  Are there any good reasons why this *shouldn't* be done?

I guess it depends somewhat on what you mean by `remotely'.  I suspect you
mean "anything other than the localhost".

I can think of one situation for which this is inconvenient.  If I set up
a local net full of debian machines, only one of which is running a web
server, this change would prevent me from using the web to browse the docs
from all the machines but one.

I won't argue that this is a "good" reason not to make the change.

It is not a tremendous burden on the admin to fix up, but a note somewhere
(`README.Debian'?  :-)) on how to enable access for a local network would
not be amiss.

-Steve

Message #66 received at 23661@bugs.debian.org (full text, mbox, reply):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

To: Steve Robbins <steve@nyongwa.montreal.qc.ca>

Cc: 23661@bugs.debian.org, security@debian.org

Subject: Re: Bug#23661: usr/doc should not be accessible through http servers by default

Date: Tue, 20 Jun 2000 14:35:24 +0100

On Tue, Jun 20, 2000 at 09:13:47AM -0400, Steve Robbins wrote:
> > Here's an issue.  About two years ago there was a proposal that the
> > default httpd setup should not allow /usr/doc to be remotely
> > accessible, as it's a huge security risk.  (Yes, we're talking about a
> > small amount of "security through obscurity" here, but we don't need
> > to hand crackers this information on a golden plate.)
> > [...]
> I can think of one situation for which this is inconvenient.  If I set up
> a local net full of debian machines, only one of which is running a web
> server, this change would prevent me from using the web to browse the docs
> from all the machines but one.

Admin's responsibility to change this.

> It is not a tremendous burden on the admin to fix up, but a note somewhere
> (`README.Debian'?  :-)) on how to enable access for a local network would
> not be amiss.

Essentially this is an implementation issue rather than a policy
issue.  Any sysadmin who's setting up a network like that should know
what to do, but I agree that a note would be helpful.  I haven't
checked the latest apache package, but such a note might even be
present ;-)

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Message #71 received at 23661@bugs.debian.org (full text, mbox, reply):

From: Chris Waters <xtifr@dsp.net>

To: Petr Cech <cech@atrey.karlin.mff.cuni.cz>

Cc: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>, security@debian.org, 23661@bugs.debian.org

Subject: Re: Bug#23661: /usr/doc should not be accessible through http servers by default

Date: Tue, 20 Jun 2000 10:19:15 -0700

On Tue, Jun 20, 2000 at 02:35:45PM +0200, Petr Cech wrote:
> On Tue, Jun 20, 2000 at 09:58:01AM +0100 , Julian Gilbey wrote:
> > Here's an issue.  About two years ago there was a proposal that the
> > default httpd setup should not allow /usr/doc to be remotely
> > accessible, as it's a huge security risk.  (Yes, we're talking about a
> > small amount of "security through obscurity" here, but we don't need
> > to hand crackers this information on a golden plate.)

> > Nothing appears to have been done about it.

> there was. At least in recent apache

Ah, but let us keep in mind that Apache is not the only httpd in
Debian.  I'm sure it's a nice server, but I'm also sure it's overkill
for my workstation, so I don't use it.

There does seem to be a bit of a tendency among some people to say
"all httpd problems can be fixed by fixing Apache," which simply isn't
true.  We also have at least: aolserver, boa (my fav), cern-httpd,
dhttpd and roxen.  And that's not even looking at non-free.
-- 
Chris Waters   xtifr@dsp.net | I have a truly elegant proof of the
      or    xtifr@debian.org | above, but it is too long to fit into
                             | this .signature file.

Message #76 received at 23661@bugs.debian.org (full text, mbox, reply):

From: Martin Schulze <joey@finlandia.Infodrom.North.DE>

To: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

Cc: security@debian.org, 23661@bugs.debian.org

Subject: Re: Bug#23661: /usr/doc should not be accessible through http servers by default

Date: Tue, 20 Jun 2000 21:09:44 +0200

Julian Gilbey wrote:
> Here's an issue.  About two years ago there was a proposal that the
> default httpd setup should not allow /usr/doc to be remotely
> accessible, as it's a huge security risk.  (Yes, we're talking about a
> small amount of "security through obscurity" here, but we don't need
> to hand crackers this information on a golden plate.)
> 
> Nothing appears to have been done about it.

I remember seeing a restriction to localhost in the config that
comes with apache.

Regards,

	Joey

-- 
This is Linux Country.  On a quiet night, you can hear Windows reboot.

Message #81 received at 23661@bugs.debian.org (full text, mbox, reply):

From: Turbo Fredriksson <turbo@debian.org>

To: debian-private@lists.debian.org

Cc: security@debian.org, 23661@bugs.debian.org

Subject: Re: Bug#23661: /usr/doc should not be accessible through http servers by default

Date: 20 Jun 2000 22:18:23 +0200

>>>>> "Martin" == Martin Schulze <joey@finlandia.Infodrom.North.DE> writes:

    Martin> Julian Gilbey wrote:
    >> Here's an issue.  About two years ago there was a proposal that
    >> the default httpd setup should not allow /usr/doc to be
    >> remotely accessible, as it's a huge security risk.  (Yes, we're
    >> talking about a small amount of "security through obscurity"
    >> here, but we don't need to hand crackers this information on a
    >> golden plate.)
    >> 
    >> Nothing appears to have been done about it.

    Martin> I remember seeing a restriction to localhost in the config
    Martin> that comes with apache.

Mon, 28 Feb 2000 08:20:27 +0100 I uploaded Roxen 1.2.122-7, which fixes
bug #59025, which I can't find in the BTS. Roxen is now at v1.3.122-11.

The entry in my changelog file reads:

  * Include a second filesystem, mounted on /doc/ (real fs: /usr/share/doc/).
    Closes: #59025

So there was a bug report against NOT to include a /doc/ mount...

-- 
spy Ft. Bragg BATF Rule Psix AK-47 subway smuggle PLO Iran Serbian
critical kibo World Trade Center president terrorist

Message #86 received at 23661@bugs.debian.org (full text, mbox, reply):

From: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

To: Raul Miller <moth@debian.org>, 23661@bugs.debian.org

Cc: security@debian.org

Subject: Re: Bug#23661: usr/doc should not be accessible through http servers by default

Date: Wed, 21 Jun 2000 18:19:29 +0100

On Tue, Jun 20, 2000 at 08:45:25AM -0400, Raul Miller wrote:
> In my opinion, this is true of all services.  Exporting them to all
> connected systems by default is a security risk.  And, while there's a lot
> we could do if the technology were better, we could at least have some
> sort of file in /etc which defines some basic policy about such things
> -- export by default vs. localhost only vs. ask user vs. export only
> "the important stuff" by default [which, unfortnately, is undecidable,
> but it's worth mentioning if only for contrast].
> [... why not ipchains ...]
> 
> What would be "really nice", of course, would be an enhancement to
> ipchains which let you make decisions on a per-program basis.  But,
> since we don't have that, I think we need a little more attention on
> getting the user involved in the configuration of exported services.
> [...]
> 
> My guess is that debconf could be pressed into service, here.  For woody,
> it would be nice to have a whole category of optional questions related to
> "do you want this exported or not".  Share some initial leading question
> or three, so that people can choose whether they want this level of detail
> at config time, and then leave the rest up to package implementation.

This sounds really interesting.  I think it needs some work before it
becomes a policy proposal, but I think this is better than just
referring to /usr/doc.

I think this is more of a "show me the code" type of situation.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Message #91 received at 23661@bugs.debian.org (full text, mbox, reply):

From: Raul Miller <moth@debian.org>

To: Julian Gilbey <J.D.Gilbey@qmw.ac.uk>

Cc: 23661@bugs.debian.org, security@debian.org

Subject: Re: Bug#23661: usr/doc should not be accessible through http servers by default

Date: Thu, 22 Jun 2000 00:54:40 -0400

> > My guess is that debconf could be pressed into service, here.  For woody,
> > it would be nice to have a whole category of optional questions related to
> > "do you want this exported or not".  Share some initial leading question
> > or three, so that people can choose whether they want this level of detail
> > at config time, and then leave the rest up to package implementation.

On Wed, Jun 21, 2000 at 06:19:29PM +0100, Julian Gilbey wrote:
> This sounds really interesting.  I think it needs some work before it
> becomes a policy proposal, but I think this is better than just
> referring to /usr/doc.
> 
> I think this is more of a "show me the code" type of situation.

I need to think through the concepts a bit more before I try tackling
code.  [A proof of concept doesn't seem hard -- what seems hard is a
not-too-ambitious statement of what I'm trying to accomplish.]

Thanks,

-- 
Raul

Message #96 received at 23661@bugs.debian.org (full text, mbox, reply):

From: steveg@molehole.dyndns.org (Steve Greenland)

To: 23661-submitter@bugs.debian.org, 23661@bugs.debian.org

Subject: Re: Bug #23661:

Date: Wed, 13 Jun 2001 13:16:53 -0500 (CDT)

This note is being sent as part of a project to clean out old (> 1yr)
debian-policy proposals. If you disagree with action below please
respond to bug#@bugs.debian.org, not to me, so that the discussion may
be carried out publically in debian-policy. Feel free to re-open the
bug while it's being discussed -- I'm not trying to force any
particular disposition, just taking my best shot at resolving dead
issues.


Bug#23661: usr/doc should not be accessible through http servers by default

Summary: suggests that http://hostname/doc/ not be available by
default, except to localhost clients. "security through obscurity"
argument raised, but consensus seemed to be that making ones entired
installed program list, including version, available to the internet
was perhaps pushing it a bit far. It was noted that later releases of
Apache and Boa restricted access, but that doesn't solve the problem
generally.It then went on to the "Well, there's a whole bunch of
services that shouldn't be available by default". Raul Miller seems to
have started examining a way to deal with this, but there's no further
note in the BTS after 22 Jun 2000.

Discussion: Policy currently says "HTML documents...can be referred to
as http://localhost/doc/package/filename". This could be sufficient to
imply that access should, by default, be restricted to localhost, but
a guiding comment or footnote should probably be added. One question
is what to do about httpds that don't support access controls.

Action: I've submitted a new proposal that addresses only the httpd
issue that refers to this one.

Message #108 received at 23661-done@bugs.debian.org (full text, mbox, reply):

From: Andreas Barth <aba@not.so.argh.org>

To: 23661-done@bugs.debian.org, 27205-done@bugs.debian.org, 33251-done@bugs.debian.org, 36151-done@bugs.debian.org, 37999-done@bugs.debian.org, 39125-done@bugs.debian.org, 42870-done@bugs.debian.org, 43724-done@bugs.debian.org, 51473-done@bugs.debian.org, 54985-done@bugs.debian.org, 62768-done@bugs.debian.org, 63598-done@bugs.debian.org, 65578-done@bugs.debian.org, 71805-done@bugs.debian.org, 78014-done@bugs.debian.org, 79541-done@bugs.debian.org, 82595-done@bugs.debian.org, 83669-done@bugs.debian.org, 85500-done@bugs.debian.org, 88058-done@bugs.debian.org, 100586-done@bugs.debian.org, 101162-done@bugs.debian.org, 102917-done@bugs.debian.org, 109171-done@bugs.debian.org, 119559-done@bugs.debian.org, 191036-done@bugs.debian.org, 197835-done@bugs.debian.org

Subject: Has been fixed for more than six month

Date: Sun, 28 Mar 2004 17:45:26 +0200

Hi,

this bug was set to the status "fixed" more than six month ago, so I'm
closing it now. For an announcement of this, see
http://lists.debian.org/debian-policy/2004/debian-policy-200403/msg00042.html


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

Send a report that this bug log contains spam.