Re: [HACKERS] libpq++ and libpqxx removed
> -Original Message- > From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] > Sent: 22 August 2002 03:25 > To: Marc G. Fournier > Cc: Christopher Kings-Lynne; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: [HACKERS] libpq++ and libpqxx removed > > The new portal isn't going to help in this regard either, I've been trying to tell you that for months. Care to let me in on that one seeing as I'm the one who's been putting blood and sweat into it? Regards, Dave. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] libpq++ and libpqxx removed
> -Original Message- > From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]] > Sent: 22 August 2002 03:28 > To: Vince Vielhaber; Marc G. Fournier > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [HACKERS] libpq++ and libpqxx removed > > > Where can we see the new portal? Maybe it should be designed > in such a way as to not use image links at all. From all my > experience in doing websites - that'd be a _really_ good idea. It doesn't use images for links. All the main links & menu items are held in a global php file so if a single change is made, it affects all pages. Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
> > 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 at your code and > you decide that "any" is the correct semantics, then fine: change > "opaque" to "any" and the warnings will go away. But relatively few > existing uses of "opaque" really mean "any", and I don't want the > people who are using "opaque" to mean "cstring", "trigger", etc > to keep using "opaque" for those other purposes. The idea here is > to force a security review. That is what I have been trying to say, imho "any" should have the same NOTICE as opaque has, since it is potentially dangerous. I would suggest a warning NOTICE for opaque and not depricate it. Imho the NOTICE should *not* go away. If we want "any" in the future, it should imho always be passed a "safe" Datum that includes type info. This will allow us to create a type "any" that does not have the pitfalls of opaque. Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Upcoming Beta
Hi. There is no need to ask me to attack a postgresql source code, as long as i remember myself, i was always in studing someone's source code or disasm output.. By the way, the code i write being a plain web programmer, even for small projects is fairly buggy:-))). One little thing saves me a bit - i am using a perl, and the code itself dont suffer from the buffer/integer overflows much, not talking about DBD::Pg. So i can repeat the above, don't ask me to do the things which i am doing 24 hours in a day... Best regards. This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com/inf/en ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Please, apply patch
Please, apply patch for tsearch to current CVS.
Patch resolve ERROR problem for non-goog query_txt.
Teodor Sigaev wrote:
> Now you can use:
> regression=# select 'the'::mquery_txt;
> ERROR: Your query contained only stopword(s), ignored
> regression=# select 'good'::mquery_txt;
> mquery_txt
>
> 'good'
> (1 row)
>
> I suggest:
> 1.
> regression=# select 'the'::mquery_txt;
> NOTICE: Your query contained only stopword(s), ignored
> mquery_txt
> -
>
> (1 row)
> 2. any operation with void query returns false:
> select t from tbl where t ## 'the';
> NOTICE: Your query contained only stopword(s), ignored
> tbl
> -
> (0 row)
>
>
>
>
>
> Christopher Kings-Lynne wrote:
>
>> Ross - maybe we could work on a little function for tsearch -
>> parse_query()
>> or something like that. It could return true or false depending on
>> whether
>> it would cause tsearch to error or not...
>>
>> Chris
>>
>>
>>> -Original Message-
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED]]On Behalf Of Ross J.
>>> Reedstrom
>>> Sent: Friday, 16 August 2002 4:59 AM
>>> To: Oleg Bartunov
>>> Cc: Christopher Kings-Lynne; Hackers
>>> Subject: Re: [HACKERS] tsearch bug in 7.2.1?
>>>
>>>
>>> On Thu, Aug 15, 2002 at 11:59:20AM +0300, Oleg Bartunov wrote:
>>>
tsearch has compiled-in stop-list, it's currently just not flexible
as OpenFTS does. We plan to move most functionality to tsearch but
currently have no time. Feel free to join us to speedup tsearch
development.
>>>
>>>
>>> Oleg -
>>> I think Chris's issue might be the same one I ran into just last night.
>>> (BTW, thanks for tsearch and the OpenFTS work, it's really great)
>>> My problem is that queries with only stopwords throw an ERROR, rather
>>> than a WARNING or NOTICE. This means We've got to deal with catching an
>>> exception so our middleware doesn't spew ugly errors and tracebacks at
>>> our endusers, and I've got to deal with cleaning up the transaction.
>>>
>>> Having the behavior be "issue a notice and return no match" would give
>>> us a reasonably functional interface: if I don't implement reading the
>>> NOTICE, I get confused users ('huh? "the" doesn't match anything?')
>>> rather than irate users ('Your search interface sucks! It keeps
>>> crashing!')
>>>
>>> Oh, well, off to implement some try: catch: logic.
>>>
>>> Ross
>>>
>>> ---(end of broadcast)---
>>> TIP 4: Don't 'kill -9' the postmaster
>>>
>>
>>
>>
>> ---(end of broadcast)---
>> TIP 3: if posting/reading through Usenet, please send an appropriate
>> subscribe-nomail command to [EMAIL PROTECTED] so that your
>> message can get through to the mailing list cleanly
>>
>
>
--
Teodor Sigaev
[EMAIL PROTECTED]
tsearch_patch.gz
Description: application/gzip
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
Gavin Sherry <[EMAIL PROTECTED]> writes: > It would be perhaps one of the most impressive hacks ever if someone > could dream machine code to put in the overrun which consisted > entirely of printable characters. At least for the x86 architecture, working ASCII-only shell code exists (even shell code which consists just of letters!). See for example: http://cert.uni-stuttgart.de/archive/vuln-dev/2000/10/msg00200.html ASCII-only shellcode for RISC platforms is even harder and might be impossible. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Release of v7.2.2 (Was: Re: [HACKERS] @(#)Mordred Labs ad...)
"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > Are we all caught up now on the known bugs/fixes? Would it be reasonably > safe to do up a quick v7.2.2 Security Fix Release tomorrow afternoon? Still need to do a release-history entry and version-stamp, of course. I will do a diff of the 7.2 branch tree this afternoon and make sure the code looks good. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Release of v7.2.2
>"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > Are we all caught up now on the known bugs/fixes? Would it be reasonably > safe to do up a quick v7.2.2 Security Fix Release tomorrow afternoon? Maybe it makes sense to wait about a week. This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com/inf/en ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: Release of v7.2.2 (Was: Re: [HACKERS] @(#)Mordred Labs ad...)
Tom, I think it's worth to include patch for query planner which fixes using indices with predicates for join plans. We found it's quite useful. http://fts.postgresql.org/db/mw/msg.html?mid=1018153 Oleg On Thu, 22 Aug 2002, Tom Lane wrote: > "Marc G. Fournier" <[EMAIL PROTECTED]> writes: > > Are we all caught up now on the known bugs/fixes? Would it be reasonably > > safe to do up a quick v7.2.2 Security Fix Release tomorrow afternoon? > > Still need to do a release-history entry and version-stamp, of course. > I will do a diff of the 7.2 branch tree this afternoon and make sure > the code looks good. > > regards, tom lane > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Release of v7.2.2 (Was: Re: [HACKERS] @(#)Mordred Labs ad...)
I was going to ask that too. I need to make up a list of 7.2.2 changes, and there are quite a number of them. I will get the list together today. --- Marc G. Fournier wrote: > > Are we all caught up now on the known bugs/fixes? Would it be reasonably > safe to do up a quick v7.2.2 Security Fix Release tomorrow afternoon? > > On Thu, 22 Aug 2002, Bruce Momjian wrote: > > > > > OK, I have applied this to 7.2.X. > > > > I have applied the lpad/rpad/repeat patch to CVS head. I assume you do > > not want the others applied to CVS head because the fixes are already present. > > > > --- > > > > Neil Conway wrote: > > > Neil Conway <[EMAIL PROTECTED]> writes: > > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > > What would you like done with the patch you submitted? > > > > > > > > I'd like to see it applied to CVS HEAD and REL7_2_STABLE. > > > > > > Uh, sorry -- wrote that without thinking. I'd like to see the patch > > > applied to REL7_2_STABLE. I'll prepare a revised patch for CVS HEAD. > > > > > > Cheers, > > > > > > Neil > > > > > > -- > > > Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC > > > > > > > > > ---(end of broadcast)--- > > > TIP 5: Have you checked our extensive FAQ? > > > > > > http://www.postgresql.org/users-lounge/docs/faq.html > > > > > > > -- > > Bruce Momjian| http://candle.pha.pa.us > > [EMAIL PROTECTED] | (610) 359-1001 > > + If your life is a hard drive, | 13 Roberts Road > > + Christ can be your backup.| Newtown Square, Pennsylvania 19073 > > > > ---(end of broadcast)--- > > TIP 3: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to [EMAIL PROTECTED] so that your > > message can get through to the mailing list cleanly > > > > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Release of v7.2.2 (Was: Re: [HACKERS] @(#)Mordred Labs ad...)
Thanks, Tom. That is a big help. I will do the release history and version stamping. --- Tom Lane wrote: > "Marc G. Fournier" <[EMAIL PROTECTED]> writes: > > Are we all caught up now on the known bugs/fixes? Would it be reasonably > > safe to do up a quick v7.2.2 Security Fix Release tomorrow afternoon? > > Still need to do a release-history entry and version-stamp, of course. > I will do a diff of the 7.2 branch tree this afternoon and make sure > the code looks good. > > regards, tom lane > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Release of v7.2.2 (Was: Re: [HACKERS] @(#)Mordred Labs ad...)
Hi everyone, It probably makes sense to wait about a week until releasing 7.2.2, even if we get assembled anything else that is needed. Sir Mordred appears to be taking a look through our 7.2.x code about now and that probably means there's a good chance we'll hear of other patches that will need to be applied to the 7.2.x branch. :-) Regards and best wishes, Justin Clift Oleg Bartunov wrote: > > Tom, > > I think it's worth to include patch for query planner which > fixes using indices with predicates for join plans. We found it's > quite useful. > > http://fts.postgresql.org/db/mw/msg.html?mid=1018153 > > Oleg -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Release of v7.2.2 (Was: Re: [HACKERS] @(#)Mordred Labs ad...)
Justin Clift <[EMAIL PROTECTED]> writes: > It probably makes sense to wait about a week until releasing 7.2.2, even > if we get assembled anything else that is needed. I think we should go ahead and push it out; by the end of next week we'll be trying to wrap 7.3 beta, and the confusion factor for pushing out two releases at the same time will be much too high. I think it is fairly unlikely that we will find anything else in the next week that is exploitable indirectly through a web-app in the same way that the date buffer overrun bug could be. Most of the sorts of bugs that I'm expecting to hear about will require being able to issue SQL commands --- and if someone can issue arbitrary SQL commands, there are plenty of ways to create a DOS situation. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
