> > Ok, now I vote, that you don't implement "any" and use "opaque".
> > I don't think we want two types that do the same thing.
> > Is it that you like the name "any" more than "opaque" ?
>
> No, it's that I want to deprecate "opaque" so that we can catch old
> uses that should not be there any
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Ok, now I vote, that you don't implement "any" and use "opaque".
> I don't think we want two types that do the same thing.
> Is it that you like the name "any" more than "opaque" ?
No, it's that I want to deprecate "opaque" so that we can
> > I did not mean visible, I meant useable, like in
> > create function xx(any) returns text ...;
> > If that is possible, what is the difference to opaque ?
>
> "any" will have the same behavior that "opaque" used to have, yes.
Ok, now I vote, that you don't implement "any" and use "opaqu
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> I did not mean visible, I meant useable, like in
> create function xx(any) returns text ...;
> If that is possible, what is the difference to opaque ?
"any" will have the same behavior that "opaque" used to have, yes.
> >> For that you would have to use "any", at the moment. This would give
> >> you the same amount of type safety you have with "opaque",
> ie, none.
>
> > I would have to use some pg_proc magic to make "any" appear there,
> > since the plan was to not make it visible at the sql level, no ?
>
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> For that you would have to use "any", at the moment. This would give
>> you the same amount of type safety you have with "opaque", ie, none.
> I would have to use some pg_proc magic to make "any" appear there,
> since the plan was to not
> > In my paper I use C functions that take "any tuple".
> > I do not yet see how I can do that without opaque if we don't
> > have a "row" but only a "trigger" type.
>
> For that you would have to use "any", at the moment. This would give
> you the same amount of type safety you have with "op
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> In my paper I use C functions that take "any tuple".
> I do not yet see how I can do that without opaque if we don't
> have a "row" but only a "trigger" type.
For that you would have to use "any", at the moment. This would give
you the s
> > May be a plan could be to leave opaque, but throw a notice
> > when it is used in a create stmt, like:
> > NOTICE: the use of type OPAQUE should be avoided where possible
>
> Right, that's exactly the plan.
>
> Actually, I think we can tighten the use of OPAQUE quite a bit, too.
> The only
On Tue, 2002-08-20 at 19:59, [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] (Greg Copeland) wrote
> > At some point in time, you have to stand and say, "the buck stops here."
> >
>
> I agree here, but at the same time you cannot put 100% of the
> responsibility on the developers. If you are the
On Tue, 2002-08-20 at 18:40, Mark Pritchard wrote:
> On Tue, 20 Aug 2002 23:48, Greg Copeland wrote:
> > On Tue, 2002-08-20 at 00:35, Dann Corbit wrote:
> > > Most computer virus problems are caused by buffer overrun. Someone
> > > decided it wasn't very important.
> >
> > This is true. IMO, it
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> How could we then disallow it's use in other context ? Seems
> if there is no restriction, "any" will be exactly as prone to
> "wrong use" as opaque was.
Well, you can always shoot yourself in the foot by creating a C function
that misinte
> > Hmm, "any" would sound like it is the same as opaque. Would "any" really be
> > all allowed types ? I think we would want to eliminate that
> altogether.
>
> Do you plan on eliminating the COUNT() aggregate, then?
Ah, you want it for aggbasetype in pg_aggregate, I did not
see that.
How c
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> They are like:
> * conv_proc(
> *INTEGER,-- source encoding id
> *INTEGER,-- destination encoding id
> *OPAQUE, -- source string (null terminated C string)
> *OPAQUE, --
> > test=# \df iso8859_1_to_utf8
> > List of functions
> > Result data type | Schema | Name| Argument data types
>
> >
>--++---+-
> > integer | p
[EMAIL PROTECTED] (Greg Copeland) wrote
> Time and time again I've read what basically amounts to, "...if someone
> can crash it it's because someone is stupid enough to allow someone to
> be able to do it in the first place..." Maybe you're right. After all,
> if core developers continue to tu
On Tue, 20 Aug 2002 23:48, Greg Copeland wrote:
> On Tue, 2002-08-20 at 00:35, Dann Corbit wrote:
> > Most computer virus problems are caused by buffer overrun. Someone
> > decided it wasn't very important.
>
> This is true. IMO, it is extremely arrogant to ignore a buffer overrun
> and announce
On Tue, 2002-08-20 at 17:15, Tom Lane wrote:
> Yes it has. CVS logs show
>
> 2002-08-04 02:44 thomas
>
> * src/backend/utils/adt/: date.c, datetime.c, format_type.c,
> nabstime.c, timestamp.c, varlena.c: Add guard code to protect from
> buffer overruns on long date/time input
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Hmm, "any" would sound like it is the same as opaque. Would "any" really be
> all allowed types ? I think we would want to eliminate that altogether.
Do you plan on eliminating the COUNT() aggregate, then?
> Imho opaque is missing a runt
On Tue, 2002-08-20 at 16:46, Zeugswetter Andreas SB SD wrote:
> > >>> Hard to say what is good for those names imho, don't like
> > >>> "anytype" :-(
> > >>
> > >> How about "any"? It's a reserved word per SQL99, I think.
> >
> > > I would actually stick to opaque in that case, already used in
> >>> Hard to say what is good for those names imho, don't like
> >>> "anytype" :-(
> >>
> >> How about "any"? It's a reserved word per SQL99, I think.
>
> > I would actually stick to opaque in that case, already used in other db's.
>
> I want to change the name because (a) we are changing th
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>> "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
>>> Hard to say what is good for those names imho, don't like
>>> "anytype" :-(
>>
>> How about "any"? It's a reserved word per SQL99, I think.
> I would actually stick to opaque
> "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> > Hard to say what is good for those names imho, don't like
> "anytype" :-(
>
> How about "any"? It's a reserved word per SQL99, I think.
I would actually stick to opaque in that case, already used in other db's.
> > I like "cstring
Nigel J. Andrews wrote:
> On Tue, 20 Aug 2002, Tom Lane wrote:
>
> > "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > >> I'd like to see something done about this fairly soon, but it's not
> > >> happening for 7.3 ...
> >
> > > Does anyone have an idea about what other functions are affected b
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Hard to say what is good for those names imho, don't like "anytype" :-(
How about "any"? It's a reserved word per SQL99, I think.
> I like "cstring", "void" and "internal".
Okay.
> Maybe "anyarray" instead of "anyarraytype".
That wou
> "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> > Would it be possible to update the system tables, so that cash_out does not take
> > opaque but really takes type money ?
>
> That is part of the solution, but only part: we have hundreds of
> functions that take "opaque" because we d
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> Would it be possible to update the system tables, so that cash_out does not take
> opaque but really takes type money ?
That is part of the solution, but only part: we have hundreds of
functions that take "opaque" because we don't currentl
> The cash_out problem can't really be fixed until we do something about
> subdividing type "opaque" into multiple pseudo-types with more carefully
> defined meanings. cash_out is declared cash_out(opaque) which does not
> really mean that it accepts any input type ... but one of the several
> m
On Tuesday 20 August 2002 12:15 pm, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Umm, but what about the reply buffer overrun advisory? I've read this
> > whole thread, and the reply advisory (AFAICT, unless I've just hit delete
> > too quickly) has NOT been addressed.
> Yes it h
Lamar Owen <[EMAIL PROTECTED]> writes:
> Umm, but what about the reply buffer overrun advisory? I've read this whole
> thread, and the reply advisory (AFAICT, unless I've just hit delete too
> quickly) has NOT been addressed.
Yes it has. CVS logs show
2002-08-04 02:44 thomas
* src/
On Tuesday 20 August 2002 11:28 am, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > But going back to the idea that it seems that the only problem being
> > publicised in the 'outside world' is the cash_out(2) version can we
> > not do the restriction on acceptable input type
Joe Conway <[EMAIL PROTECTED]> writes:
> Is there ever a reason for a user to call a function with an opaque
> parameter directly? If not, can we simply REVOKE EXECUTE for these
> functions?
Not sure, but that doesn't solve the problem for array_eq and array_dims
in any case.
Good thought thou
On Tue, Aug 20, 2002 at 11:28:32AM -0400, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > But going back to the idea that it seems that the only problem being
> > publicised in the 'outside world' is the cash_out(2) version can we
> > not do the restriction on acceptable input
Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
>
>>>I'd like to see something done about this fairly soon, but it's not
>>>happening for 7.3 ...
>>
>
>>Does anyone have an idea about what other functions are affected by this?
>
>
> As a first approximation, every output funct
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> But going back to the idea that it seems that the only problem being
> publicised in the 'outside world' is the cash_out(2) version can we
> not do the restriction on acceptable input type in order to claim that
> the fix?
Totally pointless IMHO, w
On Tue, 20 Aug 2002, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> >> I'd like to see something done about this fairly soon, but it's not
> >> happening for 7.3 ...
>
> > Does anyone have an idea about what other functions are affected by this?
>
> As a first approximation,
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> Anyone see something I missed? Tatsuo, what exactly should the function
>> signature really be for all those encoding conversion functions you just
>> added?
> test=# \df iso8859_1_to_utf8
> List of functions
> Result
> Anyone see something I missed? Tatsuo, what exactly should the function
> signature really be for all those encoding conversion functions you just
> added?
test=# \df iso8859_1_to_utf8
List of functions
Result data type | Schema | Name|
On Tue, 2002-08-20 at 08:22, D'Arcy J.M. Cain wrote:
> On August 19, 2002 11:58 pm, Rod Taylor wrote:
> > On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
> > The simple fix is to drop the money type entirely as it serves few
> > purposes -- but there are some who use it.
>
> As the or
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
>> I'd like to see something done about this fairly soon, but it's not
>> happening for 7.3 ...
> Does anyone have an idea about what other functions are affected by this?
As a first approximation, every output function for a built-in
pass-by-refere
On Tue, 2002-08-20 at 08:05, Jan Wieck wrote:
> If you say your users need direct DB access on the SQL interface level,
> I say trash your application because the data it produces isn't worth
> the magnetism on the media. It's not that we ugently need to fix such a
> bug that can only cause a DOS
Dann Corbit wrote:
> [...]
>
> What I am saying is that there is nothing that could possibly be more
> important than fixing this, except some other known problem that could
> also cause billions of dollars worth of damage. Are there any such
> problems besides the buffer overrun problems?
And
On Tue, 2002-08-20 at 00:35, Dann Corbit wrote:
>
> Most computer virus problems are caused by buffer overrun. Someone
> decided it wasn't very important.
This is true. IMO, it is extremely arrogant to ignore a buffer overrun
and announce it can't be exploited. There is many cases where this
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> On Mon, 19 Aug 2002, Tom Lane wrote:
>> I'd like to see something done about this fairly soon, but it's not
>> happening for 7.3 ...
> Can we trap and just return an error before it goes into the weeds and
> put the subdividing opaque fix in later?
I
Justin Clift wrote:
>
> Hi Mark,
>
> Mark Pritchard wrote:
> >
> [...]
> > Finally, question the due dilligence process that selects an ISP partner who
> > would leave a database open to the world, even if they run "unbreakable"
> > Oracle :)
>
> This is the one point of yours I don't feel you'
On Mon, Aug 19, 2002 at 22:35:26 -0700,
>
> Most computer virus problems are caused by buffer overrun. Someone
> decided it wasn't very important.
I disaggree with this. Most computer viruses that I see are rely on
poorly designed software and poorly trained users to propagate.
Buffer overruns
On Tue, 20 Aug 2002, D'Arcy J.M. Cain wrote:
> On August 19, 2002 11:58 pm, Rod Taylor wrote:
> > On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
> > The simple fix is to drop the money type entirely as it serves few
> > purposes -- but there are some who use it.
>
> As the original c
On August 19, 2002 11:58 pm, Rod Taylor wrote:
> On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
> The simple fix is to drop the money type entirely as it serves few
> purposes -- but there are some who use it.
As the original creator of the type I probably have the most emotional
at
On Mon, 19 Aug 2002, Tom Lane wrote:
> Justin Clift <[EMAIL PROTECTED]> writes:
> > From the info still around, this looks to mean that the cash_words()
> > problem was fixed, but the cash_out() problem was harder to fix.
>
> > Tom/Bruce, is that correct?
>
> The cash_out problem can't really b
On Mon, 19 Aug 2002, Tom Lane wrote:
> Justin Clift <[EMAIL PROTECTED]> writes:
> > From the info still around, this looks to mean that the cash_words()
> > problem was fixed, but the cash_out() problem was harder to fix.
>
> > Tom/Bruce, is that correct?
>
> The cash_out problem can't really be
> -Original Message-
> From: Mark Pritchard [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 11:27 PM
> To: Dann Corbit; Neil Conway
> Cc: Justin Clift; Tom Lane; Christopher Kings-Lynne;
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] @(#) Mordred Labs advis
On Tue, 20 Aug 2002 15:35, Dann Corbit wrote:
> Most computer virus problems are caused by buffer overrun. Someone
> decided it wasn't very important.
>
> Some computer viruses have caused billions of dollars in damage. Sounds
> important to me.
>
> "Please try our database. Someday, we hope to
> To simply decide not to fix it means:
> What I am saying is that there is nothing that could possibly be more
> important than fixing this, except some other known problem that could
> also cause billions of dollars worth of damage. Are there any such
> problems besides the buffer overrun prob
On Tue, 20 Aug 2002 15:22, Neil Conway wrote:
> I'd say the two issues are pretty different. IMHO, buffer overruns and
> similar security problems are just a special class of software bug
> (it's interesting to note that most of the buffer overruns have been
> found in the less-maintained parts of
> -Original Message-
> From: Neil Conway [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 10:48 PM
> To: Dann Corbit
> Cc: Neil Conway; Mark Pritchard; Justin Clift; Tom Lane;
> Christopher Kings-Lynne; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] @(#)
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> I read (in some other message) that this buffer overrun problem has been
> known for a very, very long time.
No, the problem you're referring to (cash_out() and friends) is *not*
a buffer overrun.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || P
> -Original Message-
> From: Neil Conway [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 10:42 PM
> To: Dann Corbit
> Cc: Neil Conway; Mark Pritchard; Justin Clift; Tom Lane;
> Christopher Kings-Lynne; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] @(#)
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> If you *know* of a buffer overrun, and simply decide not to fix it,
> that sounds very negligent to me.
*sigh*, no one is doing that, and it is pure negligence on your part
for replying to a thread that you clearly have not read.
Cheers,
Neil
--
Nei
> -Original Message-
> From: Neil Conway [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 10:22 PM
> To: Mark Pritchard
> Cc: Justin Clift; Tom Lane; Christopher Kings-Lynne;
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] @(#) Mordred Labs advisory 0x0001:
> As Tom pointed out, we've already had several releases without getting
> rid of this OPAQUE DOS bug, and as pointed out he also really doesn't
> have the patience for fixing it (yet).
>
> Was hoping we could get serious bugs fixed sooner rather than later,
> otherwise I'm afraid of us just addin
Mark Pritchard <[EMAIL PROTECTED]> writes:
> I believe its been said before, in this forum no less, that
> PostgreSQL should focus on its primary role as an RDBMS and not be
> paranoid about security. I believe it was the thread on SSL
> connections, and Tom suggested a simple ssh tunnel or vpn.
Hi Mark,
Mark Pritchard wrote:
>
> I believe its been said before, in this forum no less, that PostgreSQL should
> focus on its primary role as an RDBMS and not be paranoid about security. I
> believe it was the thread on SSL connections, and Tom suggested a simple ssh
> tunnel or vpn.
>
> Of
On Tue, 20 Aug 2002 13:40, Justin Clift wrote:
[snip]
> For example, thinking about something like the various ISP's around who
> host PostgreSQL databases; how much effort would it take to fix the
> vulnerabilities that let someone with remote access, but no ability to
> run a "trusted" language,
Rod Taylor dijo:
> The simple fix is to drop the money type entirely as it serves few
> purposes -- but there are some who use it.
There are a lot of other functions that cause the same problem. Just
dropping or fixing cash_out is not the solution.
--
Alvaro Herrera ()
One man's impedance mi
Justin Clift <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This particular hole has been in *every* release since Postgres 1.01.
> How many releases have we known about this and still done a major
> release?
Several; a quick glance in the archives shows this has been on the TODO
list since 7.
On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
> > > I'd like to see something done about this fairly soon, but it's not
> > > happening for 7.3 ...
> >
> > Hang on, you seem to be suggesting we release a major new upgrade, with
> > major new functionality, knowing it contains a way t
> > I'd like to see something done about this fairly soon, but it's not
> > happening for 7.3 ...
>
> Hang on, you seem to be suggesting we release a major new upgrade, with
> major new functionality, knowing it contains a way to trivially crash
> the backend.
>
> Err.. hang on. What happened to
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> test=> select cash_words('-70');
>> Minus twenty one million four hundred seventy four thousand eight
>> hundred thirty six dollars and forty eight cents
> It doesn't crash - but it sure is giving the wrong answe
Tom Lane wrote:
>
> Justin Clift <[EMAIL PROTECTED]> writes:
> > Hang on, you seem to be suggesting we release a major new upgrade, with
> > major new functionality, knowing it contains a way to trivially crash
> > the backend.
>
> This particular hole has been in *every* release since Postgres
Justin Clift <[EMAIL PROTECTED]> writes:
> Hang on, you seem to be suggesting we release a major new upgrade, with
> major new functionality, knowing it contains a way to trivially crash
> the backend.
This particular hole has been in *every* release since Postgres 1.01.
I'm really not intereste
> Looks like cash_words is fixed in current CVS, so I guess in 7.2.1:
>
> Welcome to psql 7.3devel, the PostgreSQL interactive terminal.
>
> Type: \copyright for distribution terms
> \h for help with SQL commands
> \? for help on internal slash
Tom Lane wrote:
>
> Justin Clift <[EMAIL PROTECTED]> writes:
> > From the info still around, this looks to mean that the cash_words()
> > problem was fixed, but the cash_out() problem was harder to fix.
>
> > Tom/Bruce, is that correct?
>
> The cash_out problem can't really be fixed until we do
Justin Clift <[EMAIL PROTECTED]> writes:
> From the info still around, this looks to mean that the cash_words()
> problem was fixed, but the cash_out() problem was harder to fix.
> Tom/Bruce, is that correct?
The cash_out problem can't really be fixed until we do something about
subdividing type
Justin Clift wrote:
> Christopher Kings-Lynne wrote:
> >
> > > On Tue, 20 Aug 2002, Justin Clift wrote:
> > >
> > > > Vince,
> > > >
> > > > Do you reckon it's worth you responding to "Sir Mordred" and pointing
> > > > out that he overstated the vulnerability?
> > >
> > > Not me. Tom (pref) or M
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Has it actually been fixed?
I couldn't reproduce a problem with his example. The buffer size in
cash_words is awfully tight though --- it's dimensioned 128 which looks
like a round number rather than a carefully calculated one, and the
requ
Justin Clift wrote:
> Hi Vince,
>
> Glad he made the advisory for something there's a fix for. :)
Oh, I see he jumpe on cash_words() and didn't mention cash_out.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If yo
Vince Vielhaber wrote:
>
> Surprised it took this long.
Yes, me too, and it says the solution is to upgrade to 7.2.1. Nope.
> -- Forwarded message --
> Date: Mon, 19 Aug 2002 15:40:28 +
> From: Sir Mordred The Traitor <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject:
Christopher Kings-Lynne wrote:
>
> > On Tue, 20 Aug 2002, Justin Clift wrote:
> >
> > > Vince,
> > >
> > > Do you reckon it's worth you responding to "Sir Mordred" and pointing
> > > out that he overstated the vulnerability?
> >
> > Not me. Tom (pref) or Marc would be the proper respondent.
>
>
> On Tue, 20 Aug 2002, Justin Clift wrote:
>
> > Vince,
> >
> > Do you reckon it's worth you responding to "Sir Mordred" and pointing
> > out that he overstated the vulnerability?
>
> Not me. Tom (pref) or Marc would be the proper respondent.
Has it actually been fixed?
Chris
--
On Tue, 20 Aug 2002, Justin Clift wrote:
> Vince,
>
> Do you reckon it's worth you responding to "Sir Mordred" and pointing
> out that he overstated the vulnerability?
Not me. Tom (pref) or Marc would be the proper respondent.
>
> :-)
>
> Regards and best wishes,
>
> Justin Clift
>
>
> Tom Lan
Vince,
Do you reckon it's worth you responding to "Sir Mordred" and pointing
out that he overstated the vulnerability?
:-)
Regards and best wishes,
Justin Clift
Tom Lane wrote:
>
> Justin Clift <[EMAIL PROTECTED]> writes:
> > Glad he made the advisory for something there's a fix for. :)
>
Justin Clift <[EMAIL PROTECTED]> writes:
> Glad he made the advisory for something there's a fix for. :)
The claim that this bug allows execution of arbitrary code is bogus anyway.
The overflow at INT_MIN will clobber the stack, yes, but in an absolutely
predetermined way; an attacker will have
Hi Vince,
Glad he made the advisory for something there's a fix for. :)
Regards and best wishes,
Justin Clift
Vince Vielhaber wrote:
>
> Surprised it took this long.
>
> Vince.
> --
> ==
> Vince Vielhaber -- KA8CSH
Surprised it took this long.
Vince.
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
http://www.camping-usa.com h
84 matches
Mail list logo
