freebsd-chat Digest, Vol 67, Issue 1
freebsd-ch...@freebsd.org
freebs...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-chat
or, via email, send a message with subject or body 'help' to
freebsd-ch...@freebsd.org
You can reach the person managing the list at
freebsd-c...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-chat digest..."
Today's Topics:
1. [OT] Re: cue images (Sergey Zaharchenko)
2. "TrustedBSD" addons (Kevin Lyons)
3. Re: "TrustedBSD" addons (Guy Helmer)
4. Re: "TrustedBSD" addons (Kevin Lyons)
5. Re: "TrustedBSD" addons (Colin Percival)
6. Re: "TrustedBSD" addons (Guy Helmer)
7. Re: "TrustedBSD" addons (Kevin Lyons)
8. Re: "TrustedBSD" addons (Paul Robinson)
9. Re: "TrustedBSD" addons (Kevin Lyons)
10. Re: "TrustedBSD" addons (Paul Robinson)
11. Re: "TrustedBSD" addons (Kevin Lyons)
12. Re: "TrustedBSD" addons (Daniel M. Kurry)
13. Re: "TrustedBSD" addons (Christian Weisgerber)
----------------------------------------------------------------------
Message: 1
Date: Tue, 29 Jun 2004 16:01:11 +0400
From: Sergey Zaharchenko <dou...@tele-kom.ru>
Subject: [OT] Re: cue images
To: artifex <art...@freemail.hu>
Cc: ch...@freebsd.org
Message-ID: <2004062912...@shark.localdomain>
Content-Type: text/plain; charset="us-ascii"
On Tue, Jun 29, 2004 at 10:36:00AM +0200,
artifex probably wrote:
> Hello!
>
> >> Where are the international standard that describe the ISO file (not
> >> the filesystem!) format?
> > \From the mount_cd9660 manpage
> >>& MOUNT_CD9660(8) FreeBSD System Manager's Manual MOUNT_CD9660(8)
> >>& NAME
> >>& mount_cd9660 - mount an ISO-9660 file system
> Ehh. Bad answer. ;-) It's for the ISO 9660 file system (as it writes),
> not the .iso file format. It's two different things.
The reason of saying that it's standard is that a file in `.iso format'
is an exact image of an ISO standard filesystem. Whatever conventions
are mentioned in the standard, they are the same in an `.iso format
file'. If ISO 9660 says the root directory starts at byte XXX, there it
starts in the image. If ISO says the integers will be encoded in both
little-endian and big-endian formats, so they are in the image.
> For example you
> can store macintosh filesystem in .iso file and you can't mount by
> mount_cd9660 of course but it still an .iso file. Right?
If the image you stored is indeed an image of an ISO filesystem, I can.
man vnconfig (4.x) or man mdconfig (5.x).
If not --- well, I can store a picture of a nude <ethnic> in JPG format
and name it to have an .iso extension. Surely we are talking about
formats, not extensions.
I don't mean the .iso extension is standard. You can make it
`.yabadabadoo' if you prefer.
I don't mean that an `.iso format file' can describe absolutely
anything (audio, etc.). But it does its job.
A waek analogy, but if I measure my weight with the device at hand and
tell you the number in kilograms, you won't object saying that I didn't
use the international platinum-iridium kilogram for my measurements? An
.iso image is an `instance' of an ISO filesystem, just as my
weightometer:) is an `instance' of that kilogram.
--
DoubleF
Excessive login or logout messages are a sure sign of senility.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-chat/attachments/20040629/86cd63d4/attachment-0001.bin
------------------------------
Message: 2
Date: Tue, 29 Jun 2004 12:28:32 -0500
From: Kevin Lyons <kevin...@ofdengineering.com>
Subject: "TrustedBSD" addons
To: freebs...@freebsd.org
Message-ID: <40E1A6C0...@ofdengineering.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
I was reading with some surprise that some of the MAC and other "addons"
from trusted bsd are to be incorporated.
I can already see the security advisories for these things like we've
had for tcpwrapper, kerberos, heimdal, jail, openssl, etcetera ad
infinitum.
Is this the right way to go? We're adding more bloat while openbsd is
cleaning itself and reworking kernal memory allocation to make exploits
near impossible.
I dloaded 5.2 but haven't installed yet. I hope there is a way to
disable the MAC and other of these "trustedbsd features" that seem to
keep DARPA funded userland people busy.
--
Kevin Lyons
OFD Engineering, 950 Threadneedle Suite 250, Houston Texas 77079
Phone: 281-679-9060, ext. 118, E-mail: kevin...@ofdengineering.com
------------------------------
Message: 3
Date: Tue, 29 Jun 2004 13:23:49 -0500
From: Guy Helmer <ghe...@palisadesys.com>
Subject: Re: "TrustedBSD" addons
To: Kevin Lyons <kevin...@ofdengineering.com>
Cc: freebs...@freebsd.org
Message-ID: <40E1B3B5...@palisadesys.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Kevin Lyons wrote:
> I was reading with some surprise that some of the MAC and other
> "addons" from trusted bsd are to be incorporated.
Old news.
> I can already see the security advisories for these things like we've
> had for tcpwrapper, kerberos, heimdal, jail, openssl, etcetera ad
> infinitum.
How many of these were developed as part of BSD? One: jail.
> Is this the right way to go? We're adding more bloat while openbsd is
> cleaning itself and reworking kernal memory allocation to make
> exploits near impossible.
That's great work. Now, let's build on that so that the entire system
is properly compartmentalized (i.e., MAC).
> I dloaded 5.2 but haven't installed yet. I hope there is a way to
> disable the MAC and other of these "trustedbsd features" that seem to
> keep DARPA funded userland people busy.
Is it so much harder to look a little more deeply at the sytem than to
write a troll/rant?
Yes, MAC is a group of kernel compile options, and they are not shipped
as part of the GENERIC kernel. From /sys/conf/NOTES:
# Support for Mandatory Access Control (MAC):
options MAC
options MAC_BIBA
options MAC_BSDEXTENDED
options MAC_DEBUG
options MAC_IFOFF
options MAC_LOMAC
options MAC_MLS
options MAC_NONE
options MAC_PARTITION
options MAC_PORTACL
options MAC_SEEOTHERUIDS
options MAC_STUB
options MAC_TEST
Please take a look at the TrustedBSD implementation before ranting about
"DARPA funded userland people". There are good reasons why these people
were funded.
Guy
------------------------------
Message: 4
Date: Tue, 29 Jun 2004 13:40:35 -0500
From: Kevin Lyons <kevin...@ofdengineering.com>
Subject: Re: "TrustedBSD" addons
Cc: freebs...@freebsd.org
Message-ID: <40E1B7A3...@ofdengineering.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
>
>> I can already see the security advisories for these things like we've
>> had for tcpwrapper, kerberos, heimdal, jail, openssl, etcetera ad
>> infinitum.
>
>
> How many of these were developed as part of BSD? One: jail.
Well, point being that more layers/lines of code added, the more
potential vulnerabilities. I don't think we can say the FreeBSD or
TrustedBSD developers are any more exploit immune than other folks.
>
>> Is this the right way to go? We're adding more bloat while openbsd is
>> cleaning itself and reworking kernal memory allocation to make
>> exploits near impossible.
>
>
> That's great work. Now, let's build on that so that the entire system
> is properly compartmentalized (i.e., MAC).
But they are not doing that, they are ONLY adding some new
functionalilty. Am I misinformed or has any vm work been done on the
level of openbsd 3.4, beyond perhaps propolice.
>
>> I dloaded 5.2 but haven't installed yet. I hope there is a way to
>> disable the MAC and other of these "trustedbsd features" that seem to
>> keep DARPA funded userland people busy.
>
>
> Is it so much harder to look a little more deeply at the sytem than to
> write a troll/rant?
Not ranting/trolling. Thanks for the info, that is good. As I said, i
have not installed/configured it yet. I have been noticing feaping
creaturism in freebsd as of late so I was simply concerned about it.
> Yes, MAC is a group of kernel compile options, and they are not shipped
> as part of the GENERIC kernel. From /sys/conf/NOTES:
>
> # Support for Mandatory Access Control (MAC):
> options MAC
> options MAC_BIBA
> options MAC_BSDEXTENDED
> options MAC_DEBUG
> options MAC_IFOFF
> options MAC_LOMAC
> options MAC_MLS
> options MAC_NONE
> options MAC_PARTITION
> options MAC_PORTACL
> options MAC_SEEOTHERUIDS
> options MAC_STUB
> options MAC_TEST
>
> Please take a look at the TrustedBSD implementation before ranting about
> "DARPA funded userland people". There are good reasons why these people
> were funded.
Hmmpf. Perhaps it is because there was some leftover when theo lost his
money :).
>
> Guy
> _______________________________________________
> freebs...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-chat
> To unsubscribe, send any mail to "freebsd-chat...@freebsd.org"
>
--
Kevin Lyons
OFD Engineering, 950 Threadneedle Suite 250, Houston Texas 77079
Phone: 281-679-9060, ext. 118, E-mail: kevin...@ofdengineering.com
------------------------------
Message: 5
Date: Tue, 29 Jun 2004 11:42:25 -0700
From: Colin Percival <colin.p...@wadham.ox.ac.uk>
Subject: Re: "TrustedBSD" addons
To: Kevin Lyons <kevin...@ofdengineering.com>
Cc: freebs...@freebsd.org
Message-ID: <6.1.0.6.1.200406...@popserver.sfu.ca>
Content-Type: text/plain; charset=us-ascii
At 10:28 29/06/2004, Kevin Lyons wrote:
>I was reading with some surprise that some of the MAC and other "addons" from trusted bsd are to be incorporated.
>
>I can already see the security advisories for these things like we've had for tcpwrapper, kerberos, heimdal, jail, openssl, etcetera ad infinitum.
It's worth noting that some of these advisories are rather esoteric.
For example, FreeBSD-SA-04:09.kadmind doesn't affect any binary
installations of FreeBSD, since it requires that both Kerberos 4 and
Kerberos 5 are built.
Meanwhile, despite having two security issues with jails (issues
which weakened jails, but did not allow any privilege beyond that of
an un-jailed user), there was one advisory (FreeBSD-SA-04:06.ipv6)
for which jails (in their default configuration) were a specific
workaround.
Colin Percival
------------------------------
Message: 6
Date: Tue, 29 Jun 2004 14:17:27 -0500
From: Guy Helmer <ghe...@palisadesys.com>
Subject: Re: "TrustedBSD" addons
To: Kevin Lyons <kevin...@ofdengineering.com>, ch...@freebsd.org
Message-ID: <40E1C047...@palisadesys.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Kevin Lyons wrote:
> >> I can already see the security advisories for these things like we've
> >> had for tcpwrapper, kerberos, heimdal, jail, openssl, etcetera ad
> >> infinitum.
> >
> >
> > How many of these were developed as part of BSD? One: jail.
>
> Well, point being that more layers/lines of code added, the more
> potential vulnerabilities. I don't think we can say the FreeBSD or
> TrustedBSD developers are any more exploit immune than other folks.
>
> >> Is this the right way to go? We're adding more bloat while openbsd is
> >> cleaning itself and reworking kernal memory allocation to make
> >> exploits near impossible.
> >
> >
> > That's great work. Now, let's build on that so that the entire system
> > is properly compartmentalized (i.e., MAC).
>
> But they are not doing that, they are ONLY adding some new
> functionalilty. Am I misinformed or has any vm work been done on the
> level of openbsd 3.4, beyond perhaps propolice.
This new functionality (if used properly) would significantly mitigate
the results of a vulnerability in any other part of the system. For
example, think of an imap server running as root but that only can read
and write files in areas of the system labeled for use by the mail
system, and additionally not allowed to make outgoing network
connections. Any exploited vulnerability (buffer overflow, race
condition, etc.) in this imap server would result in trivial access to
the system despite its running as "root".
FreeBSD has been less vulnerable to heap attacks because of the
different malloc in libc. I haven't paid attention to whether
non-executable stack pages have been considered or committed by the VM
gurus...
> >> I dloaded 5.2 but haven't installed yet. I hope there is a way to
> >> disable the MAC and other of these "trustedbsd features" that seem to
> >> keep DARPA funded userland people busy.
> >
> >
> > Is it so much harder to look a little more deeply at the sytem than to
> > write a troll/rant?
>
> Not ranting/trolling. Thanks for the info, that is good. As I said,
> i have not installed/configured it yet. I have been noticing feaping
> creaturism in freebsd as of late so I was simply concerned about it.
Good -- my "troll detector" is on alert today :-)
> > Yes, MAC is a group of kernel compile options, and they are not shipped
> > as part of the GENERIC kernel. From /sys/conf/NOTES:
> >
> > # Support for Mandatory Access Control (MAC):
> > options MAC
> > options MAC_BIBA
> > options MAC_BSDEXTENDED
> > options MAC_DEBUG
> > options MAC_IFOFF
> > options MAC_LOMAC
> > options MAC_MLS
> > options MAC_NONE
> > options MAC_PARTITION
> > options MAC_PORTACL
> > options MAC_SEEOTHERUIDS
> > options MAC_STUB
> > options MAC_TEST
> >
> > Please take a look at the TrustedBSD implementation before ranting
> about
> > "DARPA funded userland people". There are good reasons why these
> people
> > were funded.
>
> Hmmpf. Perhaps it is because there was some leftover when theo lost
> his money :).
AFAIK, the TrustedBSD project was funded before Theo's DARPA money was
stopped. I would be even more dissappointed in this incident if there
were some connection (which I doubt).
Guy
------------------------------
Message: 7
Date: Tue, 29 Jun 2004 14:20:23 -0500
From: Kevin Lyons <kevin...@ofdengineering.com>
Subject: Re: "TrustedBSD" addons
To: Colin Percival <colin.p...@wadham.ox.ac.uk>
Cc: freebs...@freebsd.org
Message-ID: <40E1C0F7...@ofdengineering.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Colin Percival wrote:
> At 10:28 29/06/2004, Kevin Lyons wrote:
>
>>I was reading with some surprise that some of the MAC and other "addons" from trusted bsd are to be incorporated.
>>
>>I can already see the security advisories for these things like we've had for tcpwrapper, kerberos, heimdal, jail, openssl, etcetera ad infinitum.
>
>
> It's worth noting that some of these advisories are rather esoteric.
> For example, FreeBSD-SA-04:09.kadmind doesn't affect any binary
> installations of FreeBSD, since it requires that both Kerberos 4 and
> Kerberos 5 are built.
>
> Meanwhile, despite having two security issues with jails (issues
> which weakened jails, but did not allow any privilege beyond that of
> an un-jailed user), there was one advisory (FreeBSD-SA-04:06.ipv6)
> for which jails (in their default configuration) were a specific
> workaround.
Some of them are not esoteric. So, following the current logic, I guess
we'll have more "jails" for jail and more wrappers for wrapper :) ?
Presumably FreeBSD r-eng runs some kind of audit on port source like
that mentioned in "Building Secure Software". Maybe that audit process
should be improved rather than trying to add more layers of paint to
fill in the cracks (proverbial)?
--
Kevin Lyons
OFD Engineering, 950 Threadneedle Suite 250, Houston Texas 77079
Phone: 281-679-9060, ext. 118, E-mail: kevin...@ofdengineering.com
------------------------------
Message: 8
Date: Tue, 29 Jun 2004 21:14:33 +0100
From: Paul Robinson <pa...@iconoplex.co.uk>
Subject: Re: "TrustedBSD" addons
To: Kevin Lyons <kevin...@ofdengineering.com>
Cc: freebs...@freebsd.org
Message-ID: <20040629201...@iconoplex.co.uk>
Content-Type: text/plain; charset=us-ascii
On Tue, Jun 29, 2004 at 01:40:35PM -0500, Kevin Lyons wrote:
> Well, point being that more layers/lines of code added, the more
> potential vulnerabilities.
Myth. Which is more vulnerable to attack - the kernel that gets compiled
when you build GENERIC, or a few lines that strcpy's some input recieved
over a socket running as root?
LOC is about as effective a measure of potential vulnerabilities as it is a
measure of how productive a developer is or the quality of the design
process - i.e. it's useless and the myth has been thrown around for god
knows how long by people who really should know better.*
Well-written code is well-written, no matter how many lines long it is.
Ditto for badly-written code. I've seen 20-liners that could be broken by a
competent 13-year old, and 20,000-liners that were impregnable. I am not
alone.
> I don't think we can say the FreeBSD or
> TrustedBSD developers are any more exploit immune than other folks.
Based on the number of security announcements over the last 5 years, I could
argue very convincingly that the FreeBSD and TrustedBSD developers are far
more exploit immune than the Microsoft OS developers.
Of course, it would be complete bullshit, but that's not the point. :-)
> Not ranting/trolling. Thanks for the info, that is good. As I said, i
> have not installed/configured it yet. I have been noticing feaping
> creaturism in freebsd as of late so I was simply concerned about it.
"Of late"? You've *JUST* noticed? Wow. :-)
* - yes, I know. I expect this now to explode into a silly thread. People
really should know better.
--
Paul Robinson
http://www.iconoplex.co.uk/
------------------------------
Message: 9
Date: Tue, 29 Jun 2004 15:30:19 -0500
From: Kevin Lyons <kevin...@ofdengineering.com>
Subject: Re: "TrustedBSD" addons
To: Paul Robinson <pa...@iconoplex.co.uk>
Cc: freebs...@freebsd.org
Message-ID: <40E1D15B...@ofdengineering.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Paul Robinson wrote:
> On Tue, Jun 29, 2004 at 01:40:35PM -0500, Kevin Lyons wrote:
>
>
>>Well, point being that more layers/lines of code added, the more
>>potential vulnerabilities.
>
>
> Myth. Which is more vulnerable to attack - the kernel that gets compiled
> when you build GENERIC, or a few lines that strcpy's some input recieved
> over a socket running as root?
>
> LOC is about as effective a measure of potential vulnerabilities as it is a
> measure of how productive a developer is or the quality of the design
> process - i.e. it's useless and the myth has been thrown around for god
> knows how long by people who really should know better.*
>
> Well-written code is well-written, no matter how many lines long it is.
> Ditto for badly-written code. I've seen 20-liners that could be broken by a
> competent 13-year old, and 20,000-liners that were impregnable. I am not
> alone.
Hmmm, sounds like the exception that proves the rule. This is a nice
argument, but with real world large projects, i.e. with all things being
more-or-less equal, more (normal distribution quality i.e. AVG) code is
more potential vulnerabilities. I (and microsoft no doubt) would love
to hear of any proof that contradicts this apparent common sense
construction. Is there an ACM or IEEE article that quantifies this?
>
>>I don't think we can say the FreeBSD or
>>TrustedBSD developers are any more exploit immune than other folks.
>
>
> Based on the number of security announcements over the last 5 years, I could
> argue very convincingly that the FreeBSD and TrustedBSD developers are far
> more exploit immune than the Microsoft OS developers.
>
> Of course, it would be complete bullshit, but that's not the point. :-)
>
>>Not ranting/trolling. Thanks for the info, that is good. As I said, i
>>have not installed/configured it yet. I have been noticing feaping
>>creaturism in freebsd as of late so I was simply concerned about it.
>
>
> "Of late"? You've *JUST* noticed? Wow. :-)
I will rephrase, I noticed enough to finally comment.
>
> * - yes, I know. I expect this now to explode into a silly thread. People
> really should know better.
>
--
Kevin Lyons
OFD Engineering, 950 Threadneedle Suite 250, Houston Texas 77079
Phone: 281-679-9060, ext. 118, E-mail: kevin...@ofdengineering.com
------------------------------
Message: 10
Date: Tue, 29 Jun 2004 21:36:24 +0100
From: Paul Robinson <pa...@iconoplex.co.uk>
Subject: Re: "TrustedBSD" addons
To: Kevin Lyons <kevin...@ofdengineering.com>
Cc: freebs...@freebsd.org
Message-ID: <20040629203...@iconoplex.co.uk>
Content-Type: text/plain; charset=us-ascii
On Tue, Jun 29, 2004 at 03:30:19PM -0500, Kevin Lyons wrote:
> Is there an ACM or IEEE article that quantifies this?
You can not write an accurate assessment of potential vulnerabilites, only
discovered ones.
It does not take a genius to work out that it only takes one line of badly
written code to introduce a vulnerability. It does not take a genius to
realise that badly written code is as much a management issue as any other.
It certainly does not take a genius to asset that well written code
impregnable code is well written and impregnable no matter how many lines of
code it is made up of.
> >"Of late"? You've *JUST* noticed? Wow. :-)
>
> I will rephrase, I noticed enough to finally comment.
Even so. :-)
--
Paul Robinson
http://www.iconoplex.co.uk/
------------------------------
Message: 11
Date: Tue, 29 Jun 2004 15:44:31 -0500
From: Kevin Lyons <kevin...@ofdengineering.com>
Subject: Re: "TrustedBSD" addons
To: Paul Robinson <pa...@iconoplex.co.uk>
Cc: freebs...@freebsd.org
Message-ID: <40E1D4AF...@ofdengineering.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Paul Robinson wrote:
> On Tue, Jun 29, 2004 at 03:30:19PM -0500, Kevin Lyons wrote:
>
>
>>Is there an ACM or IEEE article that quantifies this?
>
>
> You can not write an accurate assessment of potential vulnerabilites, only
> discovered ones.
Well then discovered vulnerabilities vs. code size? When one says
something is a Myth, it is always nice to be able to prove why?
> It does not take a genius to work out that it only takes one line of badly
> written code to introduce a vulnerability. It does not take a genius to
> realise that badly written code is as much a management issue as any other.
Does it take a genius to realize the normal distribution and random
coding errors by competent programmers occur all the time (even by
security consiious programmers) and that the more code is written,
therefore the probability of a vulnerability increases linearly?
> It certainly does not take a genius to asset that well written code
> impregnable code is well written and impregnable no matter how many lines of
> code it is made up of.
Given the perfect programmer that is a true statement.
>
>
>>>"Of late"? You've *JUST* noticed? Wow. :-)
>>
>>I will rephrase, I noticed enough to finally comment.
>
>
> Even so. :-)
>
--
Kevin Lyons
OFD Engineering, 950 Threadneedle Suite 250, Houston Texas 77079
Phone: 281-679-9060, ext. 118, E-mail: kevin...@ofdengineering.com
------------------------------
Message: 12
Date: Tue, 29 Jun 2004 17:04:31 -0500
From: "Daniel M. Kurry" <g...@over-yonder.net>
Subject: Re: "TrustedBSD" addons
To: Kevin Lyons <kevin...@ofdengineering.com>
Cc: freebs...@freebsd.org
Message-ID: <20040629220...@over-yonder.net>
Content-Type: text/plain; charset=us-ascii
Kevin Lyons said something like:
> Some of them are not esoteric. So, following the current logic, I guess
> we'll have more "jails" for jail and more wrappers for wrapper :) ?
> Presumably FreeBSD r-eng runs some kind of audit on port source like
> that mentioned in "Building Secure Software". Maybe that audit process
> should be improved rather than trying to add more layers of paint to
> fill in the cracks (proverbial)?
Kevin, I believe this is the point in the thread where someone scolds
you for not posting patches (or offering more concrete suggestions).
Just a heads up.
Dan
> --
> Kevin Lyons
------------------------------
Message: 13
Date: Wed, 30 Jun 2004 00:23:10 +0000 (UTC)
From: na...@mips.inka.de (Christian Weisgerber)
Subject: Re: "TrustedBSD" addons
To: freebs...@freebsd.org
Message-ID: <cbt15e$20hq$1...@kemoauc.mips.inka.de>
Kevin Lyons <kevin...@ofdengineering.com> wrote:
> Is this the right way to go? We're adding more bloat while openbsd is
> cleaning itself and reworking kernal memory allocation to make exploits
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> near impossible.
^^^^^^^^^^^^^^^
Er, what?
--
Christian "naddy" Weisgerber na...@mips.inka.de
------------------------------
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-chat
To unsubscribe, send any mail to "freebsd-chat...@freebsd.org"
End of freebsd-chat Digest, Vol 67, Issue 1
*******************************************