Re: [HACKERS] CommitFest 2009-09, two weeks on

Robert Haas wrote: > On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas > wrote: >>> Do you >>> have any sense of how soon you'll feel confident to commit either >>> patch? >> I'm bad at estimating. Not this week for sure, and next week I'm >> traveling and won't be able to spend as much time o

Re: [HACKERS] [PATCH] Largeobject access controls

KaiGai Kohei wrote: > I have to focus on my patches with highest priority in CommitFest, > but it may be possible to help reviewing the proposed patches in > the off-fest season. It is illegal/undesirable for the process? No, that's absolutely fine. During commitfests patch review is needed the mo

Re: [HACKERS] Could regexp_matches be immutable?

David Fetter writes: > On Wed, Oct 14, 2009 at 11:51:13PM -0400, Andrew Dunstan wrote: >> That's not the worst of it :-( See >> > This just illustrates the fact that at least as far as PostgreSQL is > concerned, OpenACS is a dead project.

Re: [HACKERS] Skip WAL in ALTER TABLE

Simon Riggs wrote: > > Is it possible to use WAL-skipping and BulkInsertState in ATRewriteTable() ? > > If ok, I'll submit a patch for the next commitfest. > > Yes Patch attached. This patch skip WAL writes during table rewrites from ALTER TABLE. Regards, --- ITAGAKI Takahiro NTT Open Source

Re: [HACKERS] Could regexp_matches be immutable?

On Wed, Oct 14, 2009 at 11:51:13PM -0400, Andrew Dunstan wrote: > > > Tom Lane wrote: >> Andrew Dunstan writes: >> >>> They are probably quite open to changing it, but IIRC it is a >>> setting imposed by OpenACS, which is what they are based on. >> >> I seem to recall having asked this before .

Re: [HACKERS] Could regexp_matches be immutable?

Tom Lane wrote: Andrew Dunstan writes: They are probably quite open to changing it, but IIRC it is a setting imposed by OpenACS, which is what they are based on. I seem to recall having asked this before ... but does OpenACS even know what they're doing here? The difference between

Re: [HACKERS] [PATCH] Largeobject access controls

Robert Haas wrote: > 2009/10/14 KaiGai Kohei : >> Robert Haas wrote: >>> On Wed, Oct 14, 2009 at 12:02 PM, Tom Lane wrote: KaiGai Kohei writes: > Tom Lane wrote: >> The most serious problem is that you ripped out myLargeObjectExists(), >> apparently because you didn't understand

Re: [HACKERS] Could regexp_matches be immutable?

Andrew Dunstan writes: > They are probably quite open to changing it, but IIRC it is a setting > imposed by OpenACS, which is what they are based on. I seem to recall having asked this before ... but does OpenACS even know what they're doing here? The difference between ERE mode and ARE mode is

Re: [HACKERS] Could regexp_matches be immutable?

Tom Lane wrote: Andrew Dunstan writes: David Fetter wrote: Speaking of which, can we see about deprecating and removing this GUC? I've yet to hear of anyone using a flavor other than the default. You have now. I have a client who sadly uses a non-default setting. And on

Re: [HACKERS] Reworks for Access Control facilities (r2363)

On Wed, Oct 14, 2009 at 9:19 PM, Tom Lane wrote: > Robert Haas writes: >> Are any of the committers willing to take a look at this?  Tom? > > I do plan to look at it tomorrow. Oh, great. You've done an impressive job slogging through a bunch of big, complex patches in the last week. Thanks, .

Re: [HACKERS] [PATCH] Largeobject access controls

2009/10/14 KaiGai Kohei : > Robert Haas wrote: >> On Wed, Oct 14, 2009 at 12:02 PM, Tom Lane wrote: >>> KaiGai Kohei writes: Tom Lane wrote: > The most serious problem is that you ripped out myLargeObjectExists(), > apparently because you didn't understand what it's there for.  The r

Re: [HACKERS] CommitFest 2009-09, two weeks on

2009/10/14 KaiGai Kohei : > Robert Haas wrote: >> On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas >> wrote:  Do you have any sense of how soon you'll feel confident to commit either patch? >>> I'm bad at estimating. Not this week for sure, and next week I'm >>> traveling and wo

Re: [HACKERS] Buffer usage in EXPLAIN and pg_stat_statements (review)

On Wed, Oct 14, 2009 at 9:38 PM, Itagaki Takahiro wrote: > > Robert Haas wrote: > >> My (limited) experience is that it's usually better to get something >> incremental committed, even if it's not what you really want.  You can >> always take another crack at the remaining issues later, but if th

Re: [HACKERS] Buffer usage in EXPLAIN and pg_stat_statements (review)

Robert Haas wrote: > My (limited) experience is that it's usually better to get something > incremental committed, even if it's not what you really want. You can > always take another crack at the remaining issues later, but if the > whole patch gets shot down then you are out of luck. Yeah, t

Re: [HACKERS] CommitFest 2009-09, two weeks on

Robert Haas wrote: > On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas > wrote: >>> Do you >>> have any sense of how soon you'll feel confident to commit either >>> patch? >> I'm bad at estimating. Not this week for sure, and next week I'm >> traveling and won't be able to spend as much time o

Re: [HACKERS] Buffer usage in EXPLAIN and pg_stat_statements (review)

2009/10/14 Itagaki Takahiro : > > Robert Haas wrote: > >> > Well, you need to find another way or risk getting the patch rejected >> > altogether. ?Those global variables are the weakest part of the whole >> > design, and I'm not going to commit a patch that destabilizes the entire >> > system for

Re: [HACKERS] Reworks for Access Control facilities (r2363)

Robert Haas wrote: > 2009/10/13 KaiGai Kohei : >> The attached patch is a revised one with the following updates: > > Despite two fairly explicit requests, this patch (and, with the > exception of ECPG, only this patch) has not yet been reviewed by a > committer. > > http://archives.postgresql.or

Re: [HACKERS] CommitFest 2009-09, two weeks on

On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas wrote: >>  Do you >> have any sense of how soon you'll feel confident to commit either >> patch? > > I'm bad at estimating. Not this week for sure, and next week I'm > traveling and won't be able to spend as much time on it as I am right > now.

Re: [HACKERS] Reworks for Access Control facilities (r2363)

Robert Haas writes: > Are any of the committers willing to take a look at this? Tom? I do plan to look at it tomorrow. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.or

Re: [HACKERS] Buffer usage in EXPLAIN and pg_stat_statements (review)

Robert Haas wrote: > > Well, you need to find another way or risk getting the patch rejected > > altogether. ?Those global variables are the weakest part of the whole > > design, and I'm not going to commit a patch that destabilizes the entire > > system for the sake of a debatable "requirement"

Re: [HACKERS] Reworks for Access Control facilities (r2363)

2009/10/13 KaiGai Kohei : > The attached patch is a revised one with the following updates: Despite two fairly explicit requests, this patch (and, with the exception of ECPG, only this patch) has not yet been reviewed by a committer. http://archives.postgresql.org/pgsql-hackers/2009-10/msg00591.p

Re: [HACKERS] [PATCH] Largeobject access controls

Robert Haas wrote: > On Wed, Oct 14, 2009 at 12:02 PM, Tom Lane wrote: >> KaiGai Kohei writes: >>> Tom Lane wrote: The most serious problem is that you ripped out myLargeObjectExists(), apparently because you didn't understand what it's there for. The reason it's there is to ensur

Re: [HACKERS] [PATCH] Largeobject access controls

Tom Lane wrote: >> The newer basis is same as other database objects, such as functions. >> But why pg_dump performs correctly for these database objects? > > The reason pg_dump works reasonably well is that it takes locks on > tables, and the other objects it dumps (such as functions) have > indi

Re: [HACKERS] Triggers on columns

Tom Lane wrote: > Applied with assorted corrections, mostly cosmetic but not entirely. > One thing you really should have caught was updating > copyfuncs/equalfuncs for the parsenode field addition. > Next time, try grepping for every reference to a struct type you > change ... Thanks for the f

Re: [HACKERS] Review of "SQLDA support for ECPG"

On Sat, Oct 10, 2009 at 2:09 PM, Boszormenyi Zoltan wrote: > Michael Meskes írta: >> On Thu, Oct 08, 2009 at 01:15:58PM +0200, Boszormenyi Zoltan wrote: >> What's the point of that?  It can't be applied without documentation, and it just makes life more complicated to have two separate p

Re: [HACKERS] Buffer usage in EXPLAIN and pg_stat_statements (review)

On Wed, Oct 14, 2009 at 9:56 AM, Tom Lane wrote: > Itagaki Takahiro writes: >> Tom Lane wrote: >>> 2. I do not understand the stuff with propagating counts into the top >>> instrumentation node. > >> It is required by contrib/pg_stat_statements. EXPLAIN wants per-node >> accumulation, but pg_sta

Re: [HACKERS] [PATCH] Largeobject access controls

On Wed, Oct 14, 2009 at 12:02 PM, Tom Lane wrote: > KaiGai Kohei writes: >> Tom Lane wrote: >>> The most serious problem is that you ripped out myLargeObjectExists(), >>> apparently because you didn't understand what it's there for.  The reason >>> it's there is to ensure that pg_dump runs don't

Re: [HACKERS] Inappropriate failure conditions in foreign_data regression test

Martin Pihlak escribió: > > By chance I noticed that the foreign_data regression test fails if run > > in an installation where "bob" is a live user. It appears to be > > assuming that half a dozen other fairly common names don't belong to > > real users, either. Could we make this a little less

Re: [HACKERS] What does this configure warning mean?

On Thu, 2009-10-15 at 00:26 +0300, Peter Eisentraut wrote: > On Wed, 2009-10-14 at 15:06 -0300, Alvaro Herrera wrote: > > Simon Riggs wrote: > > > > > > When I run ./configure, I get > > > > > > (...warning..) > > > (If you are using the official distribution of PostgreSQL then you do > > > not n

Re: [HACKERS] Rejecting weak passwords

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Peter Eisentraut writes: > > Well, you would lose anyway if the DBA switches the pg_hba.conf setting > > from md5 to password without telling you. > > True :-(. Anybody for a zero-knowledge protocol? > > (Realistically, non-password-based auth methods ar

Re: [HACKERS] What does this configure warning mean?

Peter Eisentraut writes: > On Wed, 2009-10-14 at 15:06 -0300, Alvaro Herrera wrote: >> I take it "official distribution" means "tarball" as different from a >> copy obtained thru CVS. > Maybe "If you are using an official release tarball of PostgreSQL", or > "an official release source code archi

Re: [HACKERS] Rejecting weak passwords

On 10/14/2009 06:25 PM, Peter Eisentraut wrote: On Wed, 2009-10-14 at 18:38 +0200, Magnus Hagander wrote: So throwing out a wild idea that's probably just wild enough to even consider, but one way to deal with the logging side of things would be to deprecate/remove ALTER USER/CREATE USER wit

Re: [HACKERS] Rejecting weak passwords

On 10/14/2009 06:02 PM, Dave Page wrote: On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner wrote: Well, sure, but we're talking about a client going out of their way to wrestle the point of the gun toward their own foot, aren't we? If we're worried about the user compromising their own pas

Re: [HACKERS] Rejecting weak passwords

Bruce Momjian writes: > Tom Lane wrote: >> But the main point is to hide the cleartext password, in any case. > What if we added a GUC that only allowed password changes via an SSL > connection. How's that help? The user has already exposed their new choice of password to any hypothetical eaves

Re: [HACKERS] Rejecting weak passwords

On Wed, 2009-10-14 at 18:38 +0200, Magnus Hagander wrote: > So throwing out a wild idea that's probably just wild enough to even > consider, but one way to deal with the logging side of things would be > to deprecate/remove ALTER USER/CREATE USER with password, and add a > separate API call. With a

Re: [HACKERS] Rejecting weak passwords

On Wed, 2009-10-14 at 13:08 -0400, Tom Lane wrote: > The reason to not want cleartext passwords in the logs is that the > user doesn't trust the DBA. I originally implemented the encrypt-on-the-client logic because the previous way of using ALTER USER ... PASSWORD would promiscuously leave the cle

Re: [HACKERS] Rejecting weak passwords

Peter Eisentraut writes: > Well, you would lose anyway if the DBA switches the pg_hba.conf setting > from md5 to password without telling you. True :-(. Anybody for a zero-knowledge protocol? (Realistically, non-password-based auth methods are the only real solution here, I fear. We should pro

Re: [HACKERS] Rejecting weak passwords

On 10/14/2009 05:33 PM, Dave Page wrote: On Wed, Oct 14, 2009 at 9:50 PM, Kevin Grittner wrote: Can they check the box if the provided clients include password strength checking? I'm just wondering if we're going at this the hard way, if that really is the main goal. No. Any checks

Re: [HACKERS] Could regexp_matches be immutable?

On Wed, Oct 14, 2009 at 06:06:23PM -0400, Tom Lane wrote: > Andrew Dunstan writes: > > David Fetter wrote: > >> Speaking of which, can we see about deprecating and removing this GUC? > >> I've yet to hear of anyone using a flavor other than the default. > > > You have now. I have a client who sad

Re: [HACKERS] Triggers on columns

Itagaki Takahiro writes: > column-trigger_20091014.patch is a full patch to the HEAD. Applied with assorted corrections, mostly cosmetic but not entirely. One thing you really should have caught was updating copyfuncs/equalfuncs for the parsenode field addition. Next time, try grepping for every

Re: [HACKERS] Rejecting weak passwords

On Wed, 2009-10-14 at 12:59 -0400, Tom Lane wrote: > If psql or pgAdmin takes a password and > then sends it in the clear without telling me, that's a breach of > trust > with potentially serious consequences. I might not trust the DBA, for > example, or I might be less confident of the network in

Re: [HACKERS] Rejecting weak passwords

Tom Lane wrote: > "Kevin Grittner" writes: > > And, perhaps slightly off topic: if the login password is sent over a > > non-encrypted stream, md5sum or not, can't someone use it to log in if > > they're generating their own stream to connect? > > Not if they only capture a login exchange --- the

Re: [HACKERS] Could regexp_matches be immutable?

Andrew Dunstan writes: > David Fetter wrote: >> Speaking of which, can we see about deprecating and removing this GUC? >> I've yet to hear of anyone using a flavor other than the default. > You have now. I have a client who sadly uses a non-default setting. And > on 8.4, what is more. How criti

Re: [HACKERS] Rejecting weak passwords

On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner wrote: > Dave Page wrote: > >> No. Any checks at the client are worthless, as they can be bypassed >> by 10 minutes worth of simple coding in any of a dozen or more >> languages. > > Well, sure, but we're talking about a client going out of their w

Re: [HACKERS] Could regexp_matches be immutable?

> +1 It would seem to me to be more valuable to have the benefits of > IMMUTABLE than preserve pre-7.4 compatibility forever. Just create a shell function which calls it in a specific flavor, and make that immutable. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] Rejecting weak passwords

Dave Page wrote: > No. Any checks at the client are worthless, as they can be bypassed > by 10 minutes worth of simple coding in any of a dozen or more > languages. Well, sure, but we're talking about a client going out of their way to wrestle the point of the gun toward their own foot, aren't

Re: [HACKERS] Rejecting weak passwords

Tom Lane wrote: > "Kevin Grittner" writes: >> if the login password is sent over a non-encrypted stream, md5sum >> or not, can't someone use it to log in if they're generating their >> own stream to connect? > If they see the md5'd password in a CREATE USER command, then yeah So anyone in a

Re: [HACKERS] Getting the red out (of the buildfarm)

On Sun, 2009-10-04 at 10:48 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > I understand the annoyance, but I think we do need to have an organized > > way to do testing of non-ASCII data and in particular UTF8 data, because > > there are an increasing number of special code paths for those.

Re: [HACKERS] Could regexp_matches be immutable?

On Wed, Oct 14, 2009 at 05:14:31PM -0400, Andrew Dunstan wrote: > David Fetter wrote: >> On Wed, Oct 14, 2009 at 04:51:03PM -0400, Tom Lane wrote: >> >>> Rod Taylor writes: >>> I tried making a functional index based on an expression containing the 2 argument regexp_matches() fun

Re: [HACKERS] Rejecting weak passwords

On Wed, Oct 14, 2009 at 9:50 PM, Kevin Grittner wrote: > Dave Page wrote: > >> I said up front this was a box-ticking exercise for these folks, > > Can they check the box if the provided clients include password > strength checking?  I'm just wondering if we're going at this the hard > way, if th

Re: [HACKERS] Could regexp_matches be immutable?

On 10/14/09 2:07 PM, David Fetter wrote: > On Wed, Oct 14, 2009 at 04:51:03PM -0400, Tom Lane wrote: >> Rod Taylor writes: >>> I tried making a functional index based on an expression >>> containing the 2 argument regexp_matches() function. Is there a >>> reason why this function is not marked imm

Re: [HACKERS] What does this configure warning mean?

On Wed, 2009-10-14 at 15:06 -0300, Alvaro Herrera wrote: > Simon Riggs wrote: > > > > When I run ./configure, I get > > > > (...warning..) > > (If you are using the official distribution of PostgreSQL then you do > > not need to worry about this because the Flex output is pre-generated.) > > > >

Re: [HACKERS] Rejecting weak passwords

"Kevin Grittner" writes: > And, perhaps slightly off topic: if the login password is sent over a > non-encrypted stream, md5sum or not, can't someone use it to log in if > they're generating their own stream to connect? Not if they only capture a login exchange --- the password is doubly encrypte

Re: [HACKERS] Could regexp_matches be immutable?

David Fetter wrote: > On Wed, Oct 14, 2009 at 04:51:03PM -0400, Tom Lane wrote: >> Rod Taylor writes: >> > I tried making a functional index based on an expression >> > containing the 2 argument regexp_matches() function. Is there a >> > reason why this function is not marked immutable instead of

Re: [HACKERS] Could regexp_matches be immutable?

David Fetter wrote: On Wed, Oct 14, 2009 at 04:51:03PM -0400, Tom Lane wrote: Rod Taylor writes: I tried making a functional index based on an expression containing the 2 argument regexp_matches() function. Is there a reason why this function is not marked immutable instead of normal

Re: [HACKERS] Could regexp_matches be immutable?

On Wed, Oct 14, 2009 at 04:51:03PM -0400, Tom Lane wrote: > Rod Taylor writes: > > I tried making a functional index based on an expression > > containing the 2 argument regexp_matches() function. Is there a > > reason why this function is not marked immutable instead of > > normal? > > regex_fla

Re: [HACKERS] Could regexp_matches be immutable?

Rod Taylor writes: > I tried making a functional index based on an expression containing > the 2 argument regexp_matches() function. Is there a reason why this > function is not marked immutable instead of normal? regex_flavor affects its result. regards, tom lane -- Se

Re: [HACKERS] Rejecting weak passwords

Dave Page wrote: > I said up front this was a box-ticking exercise for these folks, Can they check the box if the provided clients include password strength checking? I'm just wondering if we're going at this the hard way, if that really is the main goal. >From the point of view of usefulne

Re: [HACKERS] Rejecting weak passwords

Dave Page writes: > I said up front this was a box-ticking exercise for these folks, > however, rather than just tick the box and move on (meh - who cares if > we can store 2009-02-31 - it stores all the valid dates which are the > ones that matter :-p ) I prefer to discuss the issue and do the be

[HACKERS] Could regexp_matches be immutable?

I tried making a functional index based on an expression containing the 2 argument regexp_matches() function. Is there a reason why this function is not marked immutable instead of normal? regards, Rod Taylor -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] Rejecting weak passwords

On Wed, Oct 14, 2009 at 9:00 PM, Tom Lane wrote: > Okay, fine, so we're not looking for actual high-grade security, > we're looking to tick off a checkbox in the minds of not terribly > well-informed people.  Then the plugin mechanism as currently proposed > will do the job just fine.  We do not n

Re: [HACKERS] Rejecting weak passwords

Dave Page writes: > On Wed, Oct 14, 2009 at 7:42 PM, Greg Stark wrote: >> This whole discussion seems very strange to me. Surely any >> organization with rules like this will want them to be system-wide and >> will have already implemented them in their PAM and LDAP systems >> (assuming their not

Re: [HACKERS] Rejecting weak passwords

On 10/14/2009 12:25 PM, Tom Lane wrote: Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to throw a syntax error before you realize there's anything there that might need to be protected). And you ignored the question of insecure transmission pathways, anyway. By the time the bac

Re: [HACKERS] Rejecting weak passwords

On Wed, Oct 14, 2009 at 1:48 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Oct 14, 2009 at 12:25 PM, Tom Lane wrote: >>> Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to >>> throw a syntax error before you realize there's anything there that >>> might need to be protect

Re: [HACKERS] Rejecting weak passwords

On Wed, Oct 14, 2009 at 6:08 PM, Tom Lane wrote: > Magnus Hagander writes: >> On Wed, Oct 14, 2009 at 18:25, Tom Lane wrote: >>> Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to >>> throw a syntax error before you realize there's anything there that >>> might need to be protec

Re: [HACKERS] Rejecting weak passwords

On Wed, Oct 14, 2009 at 7:42 PM, Greg Stark wrote: > On Wed, Oct 14, 2009 at 10:28 AM, Bruce Momjian wrote: >> >> I see three checks we are trying to do on passwords: >> >>        1) Password complexity enforcement/policies >>        2) Password history - you can't reuse a password >>        3) A

Re: [HACKERS] Rejecting weak passwords

On Wed, Oct 14, 2009 at 10:28 AM, Bruce Momjian wrote: > > I see three checks we are trying to do on passwords: > >        1) Password complexity enforcement/policies >        2) Password history - you can't reuse a password >        3) Account disable after X incorrect attempts This whole discu

Re: [HACKERS] What does this configure warning mean?

Simon Riggs wrote: > > When I run ./configure, I get > > (...warning..) > (If you are using the official distribution of PostgreSQL then you do > not need to worry about this because the Flex output is pre-generated.) > > Well, I am am using the official distribution of PostreSQL and the > outpu

Re: [HACKERS] What does this configure warning mean?

Simon Riggs writes: > When I run ./configure, I get > (If you are using the official distribution of PostgreSQL then you do > not need to worry about this because the Flex output is pre-generated.) > Well, I am am using the official distribution of PostreSQL and the > output is not pre-generated

[HACKERS] What does this configure warning mean?

When I run ./configure, I get (...warning..) (If you are using the official distribution of PostgreSQL then you do not need to worry about this because the Flex output is pre-generated.) Well, I am am using the official distribution of PostreSQL and the output is not pre-generated. Clearly this

Re: [HACKERS] Rejecting weak passwords

Robert Haas writes: > On Wed, Oct 14, 2009 at 12:25 PM, Tom Lane wrote: >> Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to >> throw a syntax error before you realize there's anything there that >> might need to be protected). > It seems to me incredibly rare for anyone to iss

Re: [HACKERS] Client application name

On Oct 14, 2009, at 12:39 PM, Dave Page wrote: Isn't that cluttered enough already? I find the ps output uninformative. Having it display something that gets generated from my application would start to make it useful. Maybe what I really want is a totally different feature: log_line_p

Re: [HACKERS] Triggers on columns

Peter Eisentraut writes: > Btw., I might not get a chance to commit this within the next 48 hours. > If someone else wants to, go ahead. I will take it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subsc

Re: [HACKERS] Rejecting weak passwords

On Wed, Oct 14, 2009 at 12:25 PM, Tom Lane wrote: > Dave Page writes: >> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane wrote: >> I see one, and I proposed masking passwords in any relevant queries >> before they were written to the stats or logs to mitigate that. > > Let's see you do that (hint: "CR

Re: [HACKERS] Rejecting weak passwords

nMagnus Hagander wrote: > > Marko has pointed out repeatedly that a plugin can catch the worst > > cases of insecure passwords even when given a pre-md5'd password. > > So you can use a plugin that does it that way, or if you want you > > can use a plugin that throws error on a pre-md5'd password.

Re: [HACKERS] Client application name

Dave Page writes: > On Wed, Oct 14, 2009 at 5:37 PM, Eric B. Ridge wrote: >> I've been following this thread closely and haven't seen mention of >> including the setting as part of the process name, so a 'ps' (on Unix) would >> display it. Thoughts? > Isn't that cluttered enough already? Given

Re: [HACKERS] Rejecting weak passwords

Magnus Hagander writes: > On Wed, Oct 14, 2009 at 18:25, Tom Lane wrote: >> Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to >> throw a syntax error before you realize there's anything there that >> might need to be protected). > I'm unsure if it's our responsibility to think

Re: [HACKERS] Rejecting weak passwords

Dave Page writes: > On Wed, Oct 14, 2009 at 5:25 PM, Tom Lane wrote: >> So you can use a plugin that does it that way, or if you want you >> can use a plugin that throws error on a pre-md5'd password. > My only concern with that idea is having some way for the client to > know when to not hash t

Re: [HACKERS] Client application name

On Wed, Oct 14, 2009 at 18:39, Dave Page wrote: > On Wed, Oct 14, 2009 at 5:37 PM, Eric B. Ridge wrote: >> On Oct 13, 2009, at 11:02 AM, Dave Page wrote: >> >>> A useful feature found in other DBMSs such as MS SQL Server that has >>> been requested on these lists a few times, is the ability for a

Re: [HACKERS] Client application name

On Wed, Oct 14, 2009 at 5:37 PM, Eric B. Ridge wrote: > On Oct 13, 2009, at 11:02 AM, Dave Page wrote: > >> A useful feature found in other DBMSs such as MS SQL Server that has >> been requested on these lists a few times, is the ability for a client >> application to report its name to the server

Re: [HACKERS] Rejecting weak passwords

On Wed, Oct 14, 2009 at 18:25, Tom Lane wrote: > Dave Page writes: >> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane wrote: >> I see one, and I proposed masking passwords in any relevant queries >> before they were written to the stats or logs to mitigate that. > > Let's see you do that (hint: "CREAT

Re: [HACKERS] Client application name

On Oct 13, 2009, at 11:02 AM, Dave Page wrote: A useful feature found in other DBMSs such as MS SQL Server that has been requested on these lists a few times, is the ability for a client application to report its name to the server. I've been following this thread closely and haven't seen ment

Re: [HACKERS] Rejecting weak passwords

On Wed, Oct 14, 2009 at 5:25 PM, Tom Lane wrote: > Dave Page writes: >> On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane wrote: >> I see one, and I proposed masking passwords in any relevant queries >> before they were written to the stats or logs to mitigate that. > > Let's see you do that (hint: "CRE

[HACKERS] ECPG: store own copy of the prepared statement name

Hi, the attached patch makes ECPG more robust against applications that free() strings by storing its own copy of the prepared statement name. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more

Re: [HACKERS] Rejecting weak passwords

Dave Page writes: > On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane wrote: > I see one, and I proposed masking passwords in any relevant queries > before they were written to the stats or logs to mitigate that. Let's see you do that (hint: "CREATD USER ... PASSWORD" is going to throw a syntax error be

Re: [HACKERS] alpha 2 release notes

On Wed, 2009-10-14 at 17:35 +0300, Peter Eisentraut wrote: > In general, do we want the alpha 2 release notes as a separate section > above alpha 1, or merged with the alpha 1 notes thereby giving a > cumulative view of what happened since 8.4? Cumulative makes sense to me. Even if people are tryi

Re: [HACKERS] Rejecting weak passwords

On Wed, Oct 14, 2009 at 5:08 PM, Tom Lane wrote: > Dave Page writes: >> You've twice asserted it's a reduction without providing any arguments >> to back that up. > > You quoted two good arguments why it's insecure in your original > message, neither of which your proposed GUC does anything to pr

Re: [HACKERS] Rejecting weak passwords

Dave Page writes: > You've twice asserted it's a reduction without providing any arguments > to back that up. You quoted two good arguments why it's insecure in your original message, neither of which your proposed GUC does anything to protect against; and you also admitted that there might be ot

Re: [HACKERS] [PATCH] Largeobject access controls

KaiGai Kohei writes: > Tom Lane wrote: >> The most serious problem is that you ripped out myLargeObjectExists(), >> apparently because you didn't understand what it's there for. The reason >> it's there is to ensure that pg_dump runs don't fail. pg_dump is expected >> to produce a consistent dum

Re: [HACKERS] Rejecting weak passwords

On Wed, Oct 14, 2009 at 11:44 AM, Dave Page wrote: > On Wed, Oct 14, 2009 at 4:30 PM, Tom Lane wrote: >> Dave Page writes: >>> On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane wrote: If you're really intent on making that happen, you can have your password checker plugin reject crypted passw

Re: [HACKERS] Rejecting weak passwords

On Wed, Oct 14, 2009 at 4:30 PM, Tom Lane wrote: > Dave Page writes: >> On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane wrote: >>> If you're really intent on making that happen, you can have your >>> password checker plugin reject crypted passwords; we don't need >>> such a questionable rule in core.

Re: [HACKERS] Rejecting weak passwords

Dave Page writes: > On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane wrote: >> If you're really intent on making that happen, you can have your >> password checker plugin reject crypted passwords; we don't need >> such a questionable rule in core. > Client software would need to have a standard way to

Re: [HACKERS] Rejecting weak passwords

On 10/14/09, Dave Page wrote: > On Mon, Sep 28, 2009 at 7:37 PM, Tom Lane wrote: > > >> IOW, having plaintext password in CREATE/ALTER time which can > >> then checked for weaknesses is better that MD5 password, which > >> actually does not increase security. > > > > This is not acceptable a

Re: [HACKERS] Rejecting weak passwords

On Wed, Oct 14, 2009 at 4:11 PM, Tom Lane wrote: > Dave Page writes: >> I would suggest that in addition to the proposed plugin, we add an >> suset GUC (defaulting to OFF) which rejects any use of WITH ENCRYPTED >> PASSWORD to ensure that the password complexity can be checked when >> roles are c

Re: [HACKERS] Rejecting weak passwords

Tom Lane wrote: Dave Page writes: I would suggest that in addition to the proposed plugin, we add an suset GUC (defaulting to OFF) which rejects any use of WITH ENCRYPTED PASSWORD to ensure that the password complexity can be checked when roles are created or modified. That's going

Re: [HACKERS] Rejecting weak passwords

Dave Page writes: > I would suggest that in addition to the proposed plugin, we add an > suset GUC (defaulting to OFF) which rejects any use of WITH ENCRYPTED > PASSWORD to ensure that the password complexity can be checked when > roles are created or modified. That's going to stop us from being

Re: [HACKERS] Unicode UTF-8 table formatting for psql text output

On Tue, Oct 13, 2009 at 05:08:20PM -0400, Tom Lane wrote: > Roger Leigh writes: > > The attached updated patch renames all user-visible uses of > > "utf8" to "unicode". It also updates the documentation > > regarding "locale" to "psql client character set encoding" > > so the docs now match the c

Re: [HACKERS] Client application name

On Wed, Oct 14, 2009 at 3:42 PM, Tom Lane wrote: > Dave Page writes: >> On Tue, Oct 13, 2009 at 10:25 PM, Tom Lane wrote: >>> We have several things already that can be fed either from an >>> environment variable or an option in the connection string. >>> Is there any compelling reason why those

Re: [HACKERS] Client application name

Dave Page writes: > On Tue, Oct 13, 2009 at 10:25 PM, Tom Lane wrote: >> We have several things already that can be fed either from an >> environment variable or an option in the connection string. >> Is there any compelling reason why those two mechanisms aren't >> adequate for this? > Err, yes

[HACKERS] alpha 2 release notes

If someone wants to start working on the release notes for alpha 2, now would be a good time. In general, do we want the alpha 2 release notes as a separate section above alpha 1, or merged with the alpha 1 notes thereby giving a cumulative view of what happened since 8.4? -- Sent via pgsql-hac

  1   2   >