Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Ross J. Reedstrom [EMAIL PROTECTED] writes: On Sat, Jan 25, 2003 at 09:55:25PM -0500, Bruce Momjian wrote: If we can get them all, it is a big win. If we can't, I don't think it is a win. In the context of backporting, this is true, but in general, if you don't worry about putting locks on any of the doors, because there are other ones open, you _never_ get them all. We certainly are trying to get them all going forward. The issue here is what is reasonable to back-patch into 7.2 (or 7.3), given the ground rules that we can no longer force an initdb for users of those releases. Those ground rules mean that some bugs are unfixable in those releases. How hard should we try to back-patch fixes for fixable bugs of severity comparable to the unfixable bugs? Before you answer, consider that any time spent doing so takes away from current/future development work; fix it without regard to cost is not really a defensible stance. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Bruce, I've finished digging for stuff that seems to be appropriate to back-patch for 7.2.4. Do you have time to generate the release notes and brand the release? Attached are the CVS commit messages for all the changes in that branch since 7.2.3. regards, tom lane 2003-01-26 18:16 tgl * src/backend/commands/user.c (REL7_2_STABLE): Back-patch fixes to detoast pg_group.grolist. 2003-01-26 18:09 tgl * src/backend/access/heap/heapam.c (REL7_2_STABLE): Back-patch fixes to ensure t_ctid always has correct value (prevents some instances of 'No one parent tuple' VACUUM error, and perhaps worse things). 2003-01-26 17:33 tgl * src/: backend/utils/adt/datetime.c, test/regress/expected/timestamp.out, test/regress/expected/timestamptz.out (REL7_2_STABLE): Back-patch fix for alphabetization mistakes in datetime token tables. 2003-01-21 14:51 tgl * src/backend/access/transam/xlog.c (REL7_2_STABLE): Back-patch fix to ensure pg_clog updates are not only written but sync'ed before we consider the checkpoint to be done. 2003-01-21 14:41 tgl * src/backend/utils/adt/geo_ops.c (REL7_2_STABLE): Back-patch fixes for integer overflows in circle_poly(), path_encode(), and path_add() --- from Neil Conway. Also, repair recently-detected errors in lseg_eq(), lseg_ne(), lseg_center(). 2003-01-21 14:38 tgl * src/backend/commands/vacuum.c (REL7_2_STABLE): Back-patch fix for VACUUM being confused by SELECT FOR UPDATE of tuple that was previously outdated by a transaction that later aborted. Also, prevent VACUUM from being called inside function. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
I think we have to accept the statement that in 7.2.X malicious SQL queries can cause database failure, and fixing one or two of the ten known problems doesn't change that fact. I don't have a problem with releasing 7.2.4 and including all the fixes, including security fixes, but I don't see the security fixes _as_ _a_ _reason_ to release a 7.2.4. So, do we have non-security fixes to warrant a 7.2.X? Gavin Sherry and I have just spent a week at the Linux.conf.au. The feedback we got from users was basically this: 1. We don't allow untrusted users unlimited SQL access 2. Upgrading PostgreSQL sucks 3. We want important corruption fixes 4. So, keep supporting older versions (7.2.x at least) So, basically I think it is a VERY good idea for us to keep releasing 7.2.x versions for a long time. BTW, I'll be posting a linux.conf.au postgres report soonish... Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Neil Conway wrote: On Thu, 2003-01-16 at 22:47, Justin Clift wrote: Over the last few days we've had patches submitted for 7.2.3 that address a couple of things, both the WAL Recovery Bug that Tom has developed a patch for, and a couple of buffer overflows that have been widely reported. The buffer overflows, IMHO, are not sufficient reason to release an update. As Tom pointed out, there are lots of other, unpatched overflows in 7.2.3 (and the whole class of vulnerability requires SQL access to begin with). As for the WAL recovery bug, AFAIK no such bug has been reported in the last few days. Exactly what issue are you referring to? Let's look at the issue here --- I think security fixes are of a different class from corruption bugs or functionality bugs. For the latter, fixing those fixes actual problems in the server that actually improve the capabilities of the database. For security issues, if we already have ten open doors in a house, does it help to lock two of them when the other eight are still open? I don't see any improvement in the functionality of PostgreSQL in such a case, while feature/corruption fixes _do_ improve the backend code. I think we have to accept the statement that in 7.2.X malicious SQL queries can cause database failure, and fixing one or two of the ten known problems doesn't change that fact. I don't have a problem with releasing 7.2.4 and including all the fixes, including security fixes, but I don't see the security fixes _as_ _a_ _reason_ to release a 7.2.4. So, do we have non-security fixes to warrant a 7.2.X? -- 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
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
On Saturday 25 January 2003 20:36, Bruce Momjian wrote: improve the capabilities of the database. For security issues, if we already have ten open doors in a house, does it help to lock two of them when the other eight are still open? Yes. It depends upon which street the door faces. See the MS SQL Server Sapphire worm for reference. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] Can we revisit the thought of PostgreSQL 7.2.4?
Lamar Owen wrote: On Saturday 25 January 2003 20:36, Bruce Momjian wrote: improve the capabilities of the database. For security issues, if we already have ten open doors in a house, does it help to lock two of them when the other eight are still open? Yes. It depends upon which street the door faces. See the MS SQL Server Sapphire worm for reference. Right. All our open doors are on the inside, so we aren't too bad. -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
On Saturday 25 January 2003 21:06, Bruce Momjian wrote: Lamar Owen wrote: On Saturday 25 January 2003 20:36, Bruce Momjian wrote: improve the capabilities of the database. For security issues, if we already have ten open doors in a house, does it help to lock two of them when the other eight are still open? Yes. It depends upon which street the door faces. See the MS SQL Server Sapphire worm for reference. Right. All our open doors are on the inside, so we aren't too bad. SQL injection exploits for various frontends are also an issue. I just have an issue with being able to crash the server with an SQL command. We'll see how it pans out, I guess. Red Hat certainly thought it was worth spending some time on; reference their back porting of the fixes to versions as old as 6.5.3. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Lamar Owen wrote: On Saturday 25 January 2003 21:06, Bruce Momjian wrote: Lamar Owen wrote: On Saturday 25 January 2003 20:36, Bruce Momjian wrote: improve the capabilities of the database. For security issues, if we already have ten open doors in a house, does it help to lock two of them when the other eight are still open? Yes. It depends upon which street the door faces. See the MS SQL Server Sapphire worm for reference. Right. All our open doors are on the inside, so we aren't too bad. SQL injection exploits for various frontends are also an issue. I just have an issue with being able to crash the server with an SQL command. We'll see how it pans out, I guess. Red Hat certainly thought it was worth spending some time on; reference their back porting of the fixes to versions as old as 6.5.3. If we can get them all, it is a big win. If we can't, I don't think it is a win. -- 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: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Bruce Momjian [EMAIL PROTECTED] writes: So, do we have non-security fixes to warrant a 7.2.X? There's the order-of-operations-in-checkpoint problem, and there's one variant of the no one parent tuple was found problem that should have been patched in 7.2.3, but was overlooked. Also, the bogus-datetime-table-ordering bugs appear to exist in 7.2 (cf. recent complaint about timezone ART not being recognized). That ought to be back-patched, if we're going to make a 7.2.4, though one could certainly say that that doesn't merit a release by itself. I think there's enough to warrant a 7.2.4 ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Agreed. How do we get the patches in there, or are they there already? --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: So, do we have non-security fixes to warrant a 7.2.X? There's the order-of-operations-in-checkpoint problem, and there's one variant of the no one parent tuple was found problem that should have been patched in 7.2.3, but was overlooked. Also, the bogus-datetime-table-ordering bugs appear to exist in 7.2 (cf. recent complaint about timezone ART not being recognized). That ought to be back-patched, if we're going to make a 7.2.4, though one could certainly say that that doesn't merit a release by itself. I think there's enough to warrant a 7.2.4 ... regards, tom lane -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Bruce Momjian [EMAIL PROTECTED] writes: Agreed. How do we get the patches in there, or are they there already? We patch ;-). I've been working on it the past few days. Not quite done, but close. 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] Can we revisit the thought of PostgreSQL 7.2.4?
On Sat, 18 Jan 2003, Tom Lane wrote: PS: I'm not taking a position on Justin's suggestion that there should be a 7.2.4. Marc and Bruce would be the ones who have to do the work, so they get to make the decision... I have no problems creating one ... Bruce? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
This is an interesting thought. My gut tells me it is a viable opportunity for the corporate entities that offer support and wish to have 'VAR' status. This is just my opinion, but I view the core development group as pure development, and the various people that resell or distribute PostgreSQL as a for-profit business as those responsible for maintaining backward support. Maybe RedHat or PostgreSQL Inc can do this? It is a really good message, The best of open source, with on going support. And not to re-open a can of worms, but if PostgreSQL could upgrade without having to do a dump and restore, then this wouldn't really be an issue. Justin Clift wrote: Hi everyone, Over the last few days we've had patches submitted for 7.2.3 that address a couple of things, both the WAL Recovery Bug that Tom has developed a patch for, and a couple of buffer overflows that have been widely reported. Although we haven't wanted to release a 7.2.4, and have instead encouraged people to upgrade to 7.3.x, there are places out there who's applications aren't compatible with 7.3.x and would also need to upgrade them as well. It might be a really good idea if we re-visit the thought of 7.2.4 and have something that people running the 7.2.x series can use safely until they are able to move to 7.3.x or above. What would it take, and apart from patches for the buffer overflows and the WAL recovery bug, should anything else be included to ensure safety and stability? :-) Regards and best wishes, Justin Clift ---(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] Can we revisit the thought of PostgreSQL 7.2.4?
mlw wrote: This is an interesting thought. My gut tells me it is a viable opportunity for the corporate entities that offer support and wish to have 'VAR' status. This is just my opinion, but I view the core development group as pure development, and the various people that resell or distribute PostgreSQL as a for-profit business as those responsible for maintaining backward support. Maybe RedHat or PostgreSQL Inc can do this? It is a really good message, The best of open source, with on going support. Very interesting thought. It could probably be done. Oh, hang on... Red Hat is taking that angle for now. :-) And not to re-open a can of worms, but if PostgreSQL could upgrade without having to do a dump and restore, then this wouldn't really be an issue. That's not really true. Have personally seen applications that places use and rely on that are not yet compatible with v 7.3.x, because the vendors of the applications compiled against something that was of version 7.2.x, and doesn't work with version 7.3.x. Now, that's not our fault, and not the fault of the places running the applications, it's just part of how PostgreSQL is applied out in the real world. :-) Regards and best wishes, Justin Clift -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
On Thu, 2003-01-16 at 22:47, Justin Clift wrote: Over the last few days we've had patches submitted for 7.2.3 that address a couple of things, both the WAL Recovery Bug that Tom has developed a patch for, and a couple of buffer overflows that have been widely reported. The buffer overflows, IMHO, are not sufficient reason to release an update. As Tom pointed out, there are lots of other, unpatched overflows in 7.2.3 (and the whole class of vulnerability requires SQL access to begin with). As for the WAL recovery bug, AFAIK no such bug has been reported in the last few days. Exactly what issue are you referring to? Cheers, Neil ---(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] Can we revisit the thought of PostgreSQL 7.2.4?
Bruce Momjian wrote: Tom Lane wrote: snip PS: I'm not taking a position on Justin's suggestion that there should be a 7.2.4. Marc and Bruce would be the ones who have to do the work, so they get to make the decision... Who, us? Well, there is the confusion factor of releasing a patch to a superceeded major version. Wrapping it up and putting it out really isn't a big deal. Marc? Hi Marc, Would you be ok with us releasing a 7.2.4? :-) Regards and best wishes, Justin Clift -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Neil, Robert: As for the WAL recovery bug, AFAIK no such bug has been reported in the last few days. Exactly what issue are you referring to? That's my bug; I filed it on Wednesday. However, it is not 100%; that is: 1) While Tom and I are pretty sure that the issue *could* cause the behavior reported, we're not completely certain that it *did*; i.e. in the two reported cases, one actually turned out to be something else, and the other could possibly be something else as well. 2) Nobody has tested that switching the order of those 2 lines in 7.2.3 doesn't cause any problems, to date. I'm not saying that it's not potentially a patchable bug. We're just not ready to patch it yet. But I do vote for a 7.2.4 just because I can't upgrade a lot of my clients to 7.3.1 safely and there are a few easy patches for 7.2.3. Alternately, I would suggest an omnibus patch for the 7.2.3 source code so that we don't set a precedent for branching development. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Josh Berkus wrote: Neil, Robert: As for the WAL recovery bug, AFAIK no such bug has been reported in the last few days. Exactly what issue are you referring to? That's my bug; I filed it on Wednesday. However, it is not 100%; that is: 1) While Tom and I are pretty sure that the issue *could* cause the behavior reported, we're not completely certain that it *did*; i.e. in the two reported cases, one actually turned out to be something else, and the other could possibly be something else as well. 2) Nobody has tested that switching the order of those 2 lines in 7.2.3 doesn't cause any problems, to date. I'm not saying that it's not potentially a patchable bug. We're just not ready to patch it yet. Ok, this might not be such an important fix after all then? The wording of it at the time did make it sound important, but if it somehow has bad interactions we would be shooting ourselves in the foot with it. Any guess-timates on it's safeness and whether it really would be beneficial? But I do vote for a 7.2.4 just because I can't upgrade a lot of my clients to 7.3.1 safely and there are a few easy patches for 7.2.3. Alternately, I would suggest an omnibus patch for the 7.2.3 source code so that we don't set a precedent for branching development. An interesting thought here is to know if Red Hat fixed *all* of the known PostgreSQL security flaws for 7.2.3 with their latest security release. It would be interesting to see their code if they did so, but from Tom's previous comments it would have meant a real lot of work. It's probably better to put out a 7.2.4 than an omnibus patch though, as it gives a better foundation for everyone working on 7.2.x to safely move to. From the viewpoint of it takes more skill to patch than to compile. Regards and best wishes, Justin Clift -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
On Sunday 19 January 2003 22:16, Justin Clift wrote: An interesting thought here is to know if Red Hat fixed *all* of the known PostgreSQL security flaws for 7.2.3 with their latest security release. It would be interesting to see their code if they did so, but from Tom's previous comments it would have meant a real lot of work. Judge for yourself. Here's the text of the two Red Hat advisories (with the RPM listing and MD5 sums omitted): [For older versions] Red Hat, Inc. Red Hat Security Advisory Synopsis: Updated PostgreSQL packages fix buffer overrun vulnerabilities Advisory ID: RHSA-2003:010-10 Issue date:2003-01-14 Updated on:2003-01-14 Product: Red Hat Linux Keywords: PostgreSQL datetime lpad rpad multibyte Cross references: RHSA-2002:301 RHSA-2003:001 Obsoletes: CVE Names: CAN-2002-0972 CAN-2002-1397 CAN-2002-1398 CAN-2002-1400 CAN-2002-1401 CAN-2002-1402 - 1. Topic: Updated PostgreSQL packages are available for Red Hat Linux 6.2, 7, 7.1, and 7.2 where we have backported a number of security fixes. A separate advisory deals with updated PostgreSQL packages for Red Hat Linux 7.3 and 8.0. 2. Relevant releases/architectures: Red Hat Linux 6.2 - i386 Red Hat Linux 7.0 - i386 Red Hat Linux 7.1 - i386 Red Hat Linux 7.2 - i386, ia64 3. Problem description: PostgreSQL is an advanced Object-Relational database management system (DBMS). A number of security issues have been found that affect PostgreSQL versions shipped with Red Hat Linux. Buffer overflows in PostgreSQL 7.2 allow attackers to cause a denial of service and possibly execute arbitrary code via long arguments to the lpad or rpad functions. CAN-2002-0972 Buffer overflow in the cash_words() function for PostgreSQL 7.2 and earlier allows local users to cause a denial of service and possibly execute arbitrary code via a malformed argument. CAN-2002-1397 Buffer overflow in the date parser for PostgreSQL before 7.2.2 allows attackers to cause a denial of service and possibly execute arbitrary code via a long date string, also known as a vulnerability in handling long datetime input. CAN-2002-1398 Heap-based buffer overflow in the repeat() function for PostgreSQL before 7.2.2 allows attackers to execute arbitrary code by causing repeat() to generate a large string. CAN-2002-1400 Buffer overflows in circle_poly, path_encode and path_add allow attackers to cause a denial of service and possibly execute arbitrary code. Note that these issues have been fixed in our packages and in PostgreSQL CVS, but are not included in PostgreSQL version 7.2.2 or 7.2.3. CAN-2002-1401 Buffer overflows in the TZ and SET TIME ZONE enivronment variables for PostgreSQL 7.2.1 and earlier allow local users to cause a denial of service and possibly execute arbitrary code. CAN-2002-1402 Note that these vulnerabilities are only critical on open or shared systems because connecting to the database is required before the vulnerabilities can be exploited. The PostgreSQL Global Development Team has released versions of PostgreSQL that fixes these vulnerabilities, and these fixes have been isolated and backported to the various versions of PostgreSQL that originally shipped with each Red Hat Linux distribution. All users of PostgreSQL are advised to install these updated packages. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. Please note that this update is available via Red Hat Network. To use Red Hat Network, launch the Red Hat Update Agent with the following command: up2date This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. Note that no initdb will be necessary from previous PostgreSQL packages. 5. RPMs required: [omitted] [For recent versions] Red Hat, Inc. Red Hat Security Advisory Synopsis: Updated PostgreSQL packages fix security issues and bugs Advisory ID: RHSA-2003:001-16 Issue date:2003-01-14 Updated on:2003-01-14 Product: Red Hat Linux Keywords: PostgreSQL VACUUM pre-1970 spinlock Cross references: Obsoletes: CVE Names: CAN-2002-0972 CAN-2002-1397 CAN-2002-1398 CAN-2002-1400 CAN-2002-1401 CAN-2002-1402 - 1. Topic: Updated PostgreSQL packages are available for Red Hat Linux 7.3 and 8.0. These packages correct several security and other bugs. A separate advisory deals with updated PostgreSQL packages for Red Hat Linux 6.2, 7, 7.1, and 7.2. 2. Relevant releases/architectures: Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 3. Problem description: PostgreSQL is an advanced Object-Relational database management system. Red Hat Linux 7.3 shipped with PostgreSQL version 7.2.1.
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Lamar Owen [EMAIL PROTECTED] writes: ... Why? If a user doesn't need the features of 7.x.x, and the codebase is working well for him/her, why should said user/DBA feel compelled to go through who knows what mechanations to upgrade to the latest version? Because there are unfixable bugs in the older versions. I see very little point in issuing security updates that fix individual buffer overruns, when anyone who has the SQL-level access needed to trigger one of those overruns can equally easily do select cash_out(2). The only fix for that is an upgrade to 7.3. I don't by any means have a problem with Red Hat issuing maintenance releases against old versions (nor, as I said, do I have any objection to a 7.2.4 community release; I just said it wasn't my decision to make). What I am questioning is the value of fixing some security holes when there are bigger, unfixable ones right next door. It wastes time that could be spent on other work, and it may give DBAs a false sense of security. Sure I'm safe; I just got the latest security patch from Red Hat, so my 6.5.3 Postgres must be bulletproof now! 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
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
On Saturday 18 January 2003 11:13, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: ... Why? If a user doesn't need the features of 7.x.x, and the codebase is working well for him/her, why should said user/DBA feel compelled to go through who knows what mechanations to upgrade to the latest version? Because there are unfixable bugs in the older versions. I see very little point in issuing security updates that fix individual buffer overruns, when anyone who has the SQL-level access needed to trigger one of those overruns can equally easily do select cash_out(2). The only fix for that is an upgrade to 7.3. And the cure might be worse than the disease; that is my point. It wastes time that could be spent on other work, and it may give DBAs a false sense of security. Sure I'm safe; I just got the latest security patch from Red Hat, so my 6.5.3 Postgres must be bulletproof now! Red Hat issued a very detailed synopsis of what was fixed. Also, one man's wasted time is another man's time well spent. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] Can we revisit the thought of PostgreSQL 7.2.4?
On Thursday 16 January 2003 22:47, Justin Clift wrote: Although we haven't wanted to release a 7.2.4, and have instead encouraged people to upgrade to 7.3.x, there are places out there who's applications aren't compatible with 7.3.x and would also need to upgrade them as well. Incidentally, has anyone else noticed the security update onslaught from Red Hat for older PostgreSQL versions? They even backported the fixes to 6.5.3 from Red Hat 6.2 (as well as for 7.0 and 7.1 as released in the respective Red Hat Linux versions). Should I forward that notice here? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Lamar Owen [EMAIL PROTECTED] writes: Incidentally, has anyone else noticed the security update onslaught from Red Hat for older PostgreSQL versions? They even backported the fixes to 6.5.3 from Red Hat 6.2 (as well as for 7.0 and 7.1 as released in the respective Red Hat Linux versions). Should I forward that notice here? Some of the guys in Toronto got excited about it, but I can't see a lot of value there myself. If you're still running 6.5.3, is it likely you notice updates from anywhere? Red Hat 6.2 is still nominally supported (until March 31, it says here) so I suppose there's a corporate compulsion to back-patch anything that's labeled a security issue. But let's get real ... PG 6.anything is stone-age code now. regards, tom lane Red Hat Database project PS: I'm not taking a position on Justin's suggestion that there should be a 7.2.4. Marc and Bruce would be the ones who have to do the work, so they get to make the decision... ---(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] Can we revisit the thought of PostgreSQL 7.2.4?
On Saturday 18 January 2003 00:08, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: Incidentally, has anyone else noticed the security update onslaught from Red Hat for older PostgreSQL versions? They even backported the fixes to 6.5.3 from Red Hat 6.2 (as well as for 7.0 and 7.1 as released in the respective Red Hat Linux versions). Should I forward that notice here? Some of the guys in Toronto got excited about it, but I can't see a lot of value there myself. If you're still running 6.5.3, is it likely you notice updates from anywhere? Why not? Upgrading to another major version of most things isn't supported by Red Hat within a particular version. KDE is a prime example. GNOME is another. XFree86 is another. BIND is yet another, although BIND8 upgrades are available for the systems that shipped with BIND4. RPM itself is one of the few exceptions. Going to 7.3 from 6.5 is not an update. And lots of sites are still running 6.2. IIRC Red Hat's up2date automatic upgrader tool was available in 6.2, and I know other autoupdaters are available. And, as we all know, automatic upgrade of PostgreSQL is only possible within a major version. Plenty of security conscious people still run Red Hat 6.2. Many probably pay for the enterprise support contracts through Red Hat, costing much money. Hmmmph, I know of a user running a couple of sites still running 5.2, with no intention of upgrading those machines. Will PostgreSQL 7.3 even build on Red Hat Linux 5.2? Forced upgrades are nonsense. So I'm glad Red Hat decided to put resources into supporting their userbase (even given the sunset on said support). On the BSD front, OpenBSD in particular still is running ancient versions of some core network stuff, due to the extreme security nature of that OS. Last I looked at OBSD it still shipped BIND4. 4.9 something. Positively ancient code that they have thoroughly audited. BIND8 hadn't at that time been fully audited. Red Hat 6.2 is still nominally supported (until March 31, it says here) so I suppose there's a corporate compulsion to back-patch anything that's labeled a security issue. But let's get real ... PG 6.anything is stone-age code now. Why? If a user doesn't need the features of 7.x.x, and the codebase is working well for him/her, why should said user/DBA feel compelled to go through who knows what mechanations to upgrade to the latest version? That's Microsoft-think. The upgrade from a 6.5.3 system to a 7.3.1 system is likely to be traumatic at least and cataclysmic at worst (to upgrade PostgreSQL may require upgrading the whole OS, which may require more memory (maybe more memory than the motherboard will support, even)). Yes, let's get real -- not everybody needs or necessarily even wants all the improved features of PG 7.3 versus even 6.5. The 'corporate compulsion' you mentioned is more widely known as 'customer service.' IOW, you want to stay in business, you support your customers. The Red Hat 5.2 user mentioned previously is perfectly happy with the featureset of PostgreSQL 6.3.2 (which is what 5.2 shipped with) and won't upgrade until it's very necessary. But this is a very low resource machine, where even the Linux 2.0 kernel makes sense. Now 6.5.3 will build on 5.2, but I haven't tried anything more recent. And 6.3.2 is enough database for their uses -- but these machines are in roles where security issues could be problematic. If it were easier to upgrade, they might consider it. _Of_course_ I'm not advocating that _we_ support these old of systems (after all, the PostgreSQL Global Development Group _has_ no customers) -- but it _is_ nice when a distributor acknowledges their older customers with real security updates within their released versions, and doesn't force major upgrades when unnecessary. Now if the user needs _features_ then the upgrade is justified, and I have no sympathy for a user who wants, say, schema support backpatched to 7.0.3, for instance. That request is just ridiculous. But for security and critical bugfixes, it should not be a forced major version upgrade, unless the bugfix cannot be easily backported. I for one intend to get the source RPM's for the fixed packages -- who knows, maybe some of the patches include the ability to rebuild on later Red Hat Linux versions, helping my upgradability crusade a little. As to the 7.2.4 issue, much if not all of our userbase is more than used to multiple concurrent OS kernel branches. Linux users in particular are very used to parallel versions -- the 2.0.x and 2.2.x series still get occassional releases even with 2.4.x out, and the development versions are in parallel constantly (except during the first few versions of a recent stable) with stable releases.. FreeBSD has their branches, etc. I think we should release a 7.2.4 if the bugfixes warrant it. (Not a 7.1.4, though, or 7.0.4, or 6.5.4, or 6.4.3, or 6.3.3,
Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?
Tom Lane wrote: Red Hat 6.2 is still nominally supported (until March 31, it says here) so I suppose there's a corporate compulsion to back-patch anything that's labeled a security issue. But let's get real ... PG 6.anything is stone-age code now. regards, tom lane Red Hat Database project PS: I'm not taking a position on Justin's suggestion that there should be a 7.2.4. Marc and Bruce would be the ones who have to do the work, so they get to make the decision... Who, us? Well, there is the confusion factor of releasing a patch to a superceeded major version. Wrapping it up and putting it out really isn't a big deal. Marc? -- 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
