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 anymore. If you look
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 could we
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 misinterprets its
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 is extremely
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
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 supported
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 same amount of
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 opaque, ie, none.
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 make it
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 ?
Huh? It'll be
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.
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 opaque.
I don't
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 catch old
uses
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 fixed until
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 fixed
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
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 creator
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
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've quite got
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 don't
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
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 what
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 in
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-reference
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 original
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 data type
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, every output
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, when the
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 function for a built-in
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 type in
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 in order
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
*
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 has. CVS
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
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 currently have
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
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 would match with any.
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, void and
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 in that case, already
[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 turn a
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 the semantics,
(b) we
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 other db's.
I want
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 runtime type
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
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 it
test=# \df iso8859_1_to_utf8
List of functions
Result data type | Schema | Name| Argument data types
--++---+-
integer | pg_catalog |
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, --
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
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 -- KA8CSHemail:
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 no
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. :)
The
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 Lane 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.
Has it actually been fixed?
Chris
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.
Has it actually been
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: @(#)
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 your
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
required
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 Marc would be the proper
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 [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 interested in
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 answer ;)
Well,
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 our
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 to trivially
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
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 (alvherre[a]atentus.com)
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, take
Hi Mark,
Mark Pritchard wrote:
snip
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
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.
I'd
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 adding
-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:
Buffer overflow
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
--
Neil
-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] @(#) Mordred Labs advisory 0x0001
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] || PGP Key
-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] @(#) Mordred Labs advisory 0x0001
To simply decide not to fix it means:
snip
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
75 matches
Mail list logo
