Re: [HACKERS] scram and \password
On Tue, Apr 25, 2017 at 8:56 PM, Heikki Linnakangas wrote: > On 04/22/2017 01:20 AM, Michael Paquier wrote: > >> On Sat, Apr 22, 2017 at 5:04 AM, Heikki Linnakangas >> wrote: >> >>> I'll continue reviewing the rest of the patch on Monday, but one glaring >>> issue is that we cannot add an argument to the existing libpq >>> PQencryptPassword() function, because that's part of the public API. It >>> would break all applications that use PQencryptPassword(). >>> >>> What we need to do is to add a new function. What should we call that? We >>> don't have a tradition of using "Ex" or such suffix to mark extended >>> versions of existing functions. PQencryptPasswordWithMethod(user, pass, >>> method) ? >>> >> >> Do we really want to add a new function or have a hard failure? Any >> application calling PQencryptPassword may trap itself silently if the >> server uses scram as hba key or if the default is switched to that, >> from this point of view extending the function makes sense as well. >> > > Yeah, there is that. But we simply cannot change the signature of an > existing function. It would not only produce compile-time errors when > building old applications, which would arguably be a good thing, but it > would also cause old binaries to segfault when dynamically linked with the > new libpq. > > I think it's clear that we should have a new function that takes the > algorithm as argument. But there are open decisions on what the old > PQencryptPassword() function should do, and also what the new function > should do by default, if you don't specify an algorithm: > > A) Have PQencryptPassword() return an md5 hash. > > B) Have PQencryptPassword() return a SCRAM verifier > > C) Have PQencryptPassword() return a SCRAM verifier if connected to a v10 > server, and an md5 hash otherwise. This is tricky, because > PQencryptPassword doesn't take a PGconn argument. It could behave like > PQescapeString() does, and choose md5/scram depending on the server version > of the last connection that was established. > > For the new function, it's probably best to pass a PGconn argument. That > way we can use the connection to determine the default, and it seems to be > a good idea for future-proofing too. And an extra "options" argument might > be good, while we're at it, to e.g. specify the number of iterations for > SCRAM. So all in all, I propose the documentation for these functions to be > (I chose option C from above for this): > > > char * > PQencryptPasswordConn(PGconn *conn, > const char *passwd, > const char *user, > const char *method, > const char *options) > I was just thinking: - Do we need to provide the method here? We have connection object itself, it can decide from the type of connection, which method to be used. -- Thanks, Ashesh > > [this paragraph is the same as current PQencryptPassword()] > This function is intended to be used by client applications that wish to > send commands like ALTER ROLE joe PASSWORD 'pwd'. It is good practice to > not send the original cleartext password in such a command, because it > might be exposed in command logs, activity displays and so on. Instead, use > this function to convert the password to encrypted form before it is sent. > [end of unchanged part] > > This function may execute internal queries to the server to determine > appropriate defaults, using the given connection object. The call can > therefore fail if the connection is busy executing another query, or the > current transaction is aborted. > > The return value is a string allocated by malloc, or NULL if out of memory > or other error. On error, a suitable message is stored in the 'conn' > object. The caller can assume the string doesn't contain any special > characters that would require escaping. Use PQfreemem to free the result > when done with it. > > The function arguments are: > > conn > Connection object for the database where the password is to be changed. > > passwd > The new password > > user > Name of the role whose password is to be changed > > method > Name of the password encryption method to use. Currently supported > methods are "md5" or "scram-sha-256". If method is NULL, the default for > the current database is used. [i.e. this looks at password_encryption] > > options > Options specific to the encryption method, or NULL to use the defaults. > (This argument is for future expansion, there are currently no options, and > you should always pass NULL.) > > > char * > PQencryptPassword(const char *passwd, const char *user) > > PQencryptPassword is an older, deprecated version of PQencryptPasswodConn. > The difference is that PQencryptPassword does not require a connection > object. The encryption method will be chosen depending on the server > version of the last established connection, and built-in default options. > > > > Thoughts? Unless someone has better ideas or objections, I'l
Re: [HACKERS] scram and \password
On Thu, Apr 27, 2017 at 9:57 AM, Michael Paquier wrote: > On Thu, Apr 27, 2017 at 1:25 PM, Ashesh Vashi > wrote: > > - Do we need to provide the method here? > > We have connection object itself, it can decide from the type of > connection, > > which method to be used. > > Providing the method is not mandatory. If you look upthread... If the > caller of this routine specified method = NULL, then the value of > password_encryption on the server is queried automatically and that > will be the method used to hash the password. > I missed that. Sorry. Thanks. --Thanks, Ashesh > -- > Michael >
Re: [HACKERS] narwhal and PGDLLIMPORT
On Mon, Feb 3, 2014 at 6:52 AM, Craig Ringer wrote: > On 02/02/2014 09:03 AM, Tom Lane wrote: > > According to the buildfarm database, narwhal is running a gcc build on > > Windows 2003. That hardly seems like a mainstream use case. I could > > believe that it might be of interest to developers, but clearly no > > developers are actually running such a build. > > > > I think we should give serious consideration to desupporting this > > combination > > I'm not a fan of MinGW (gcc) on Windows, it's a right pain. It's also > the only open source compiler currently supported for PostgreSQL on > Windows - practically the only one available. I don't know about you, > but I'm not too keen on assuming Microsoft will continue to offer free > toolchains that're usable for our purposes. They're crippling their free > build tools more and more with each release, which isn't a good trend. > > If you wish to eliminate PGDLLIMPORT from the codebase the correct > approach would be building with --export-all-symbols (a MinGW extension > flag to gcc). That would make the MinGW builds consistent with the MSVC > build, which generates a .def file that exports all symbols. > > As for why PGDLLIMPORT appears to be required in some places on the MSVC > build, so far it's looking like we auto-export functions, but not > necessarily variables. In my experience, that is true. During some contrib module development, while accessing a postgresql variable it was crashing on windows, while same was accessible in non-windows platform. > I'd need to read the fairly scary MSVC build > genreator scripts in detail to confirm that, to see how they produce > their DEF files; that'll have to wait until after I've got the > row-security work sorted out. > > -- > Craig Ringer http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- -- Thanks & Regards, Ashesh Vashi EnterpriseDB INDIA: Enterprise PostgreSQL Company<http://www.enterprisedb.com> *http://www.linkedin.com/in/asheshvashi*<http://www.linkedin.com/in/asheshvashi>
Re: [HACKERS] Missing plpgsql.o Symbols on OS X
Please add -arch x86_64 to your LD_FLAGS and CFLAGS in your make file. -- Thanks & Regards, Ashesh Vashi EnterpriseDB INDIA: Enterprise PostgreSQL Company <http://www.enterprisedb.com> *http://www.linkedin.com/in/asheshvashi* <http://www.linkedin.com/in/asheshvashi> On Wed, Aug 27, 2014 at 9:29 PM, David E. Wheeler wrote: > Hackers, > > I’m trying to build Pavel’s plpgsql_check against the 9.4 beta on OS X > 10.9, but get these errors: > > make > gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute > -Wformat-security -fno-strict-aliasing -fwrapv > -I/usr/local/pgsql/lib/pgxs/src/makefiles/../../src/pl/plpgsql/src -bundle > -multiply_defined suppress -o plpgsql_check.so plpgsql_check.o > -L/usr/local/pgsql/lib -L/usr/local/lib -L/usr/local/lib > -Wl,-dead_strip_dylibs -bundle_loader /usr/local/pgsql/bin/postgres > Undefined symbols for architecture x86_64: > "_exec_get_datum_type", referenced from: > _check_target in plpgsql_check.o > "_plpgsql_build_datatype", referenced from: > _check_stmt in plpgsql_check.o > "_plpgsql_compile", referenced from: > _check_plpgsql_function in plpgsql_check.o > "_plpgsql_parser_setup", referenced from: > _prepare_expr in plpgsql_check.o > "_plpgsql_stmt_typename", referenced from: > _put_error in plpgsql_check.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > make: *** [plpgsql_check.so] Error 1 > > Which is odd, because plpgsql_check.c includes plpgsql.h, and those > symbols do appear to be in plpgsql.so: > > $ nm /usr/local/pgsql/lib/plpgsql.so | grep _exec_get_datum_type > f110 T _exec_get_datum_type > f380 T _exec_get_datum_type_info > > So, uh, what gives? Do I need to something extra to get it to properly > find plpgsql.so? > > Thanks, > > David > >
Re: [HACKERS] PostgreSQL Core Team
Congrats Magnus!!! Thanks for the smart work and keep it up... -- Thanks & Regards, Ashesh Vashi EnterpriseDB INDIA: Enterprise PostgreSQL Company<http://www.enterprisedb.com> *http://www.linkedin.com/in/asheshvashi*<http://www.linkedin.com/in/asheshvashi> On Thu, Apr 28, 2011 at 12:18 AM, Dave Page wrote: > I'm pleased to announce that effective immediately, Magnus Hagander > will be joining the PostgreSQL Core Team. > > Magnus has been a contributor to PostgreSQL for over 12 years, and > played a major part in the development and ongoing maintenance of the > native Windows port, quickly becoming a committer to help with his > efforts. He's one of the project's webmasters and sysadmins and also > contributes to related projects such as pgAdmin. In his spare time, he > serves as President of the Board of PostgreSQL Europe. > > Regards, Dave. > > -- > Dave Page > PostgreSQL Core Team > http://www.postgresql.org/ > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- -- Thanks & Regards, Ashesh Vashi EnterpriseDB INDIA: Enterprise Postgres Company<http://www.enterprisedb.com> *http://www.linkedin.com/in/asheshvashi*<http://www.linkedin.com/in/asheshvashi>
[HACKERS] PATCH: Compiling PostgreSQL using ActiveState Python 3.2
Hi,
I am trying to build PostgreSQL 9.1beta3 using the ActiveState Python 3.2.
It did not compile successfully.
When I tried to figure out the exact reason for the failure, I found that:
1. 'python_configdir' variable is hardcoded, instead it should use the
configuration 'LIBPL'.
2. 'plpython' is trying get linked using '-lpython${*python_version*}', but
it should be '-lpython${*python_ldversion*}'.
Please find the attached patch, which resolve the issue on my side.
--
Thanks & Regards,
Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company<http://www.enterprisedb.com>
*http://www.linkedin.com/in/asheshvashi*
pg9.1beta3_python.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: Compiling PostgreSQL using ActiveState Python 3.2
On Thu, Aug 18, 2011 at 1:25 AM, Tom Lane wrote:
> Peter Eisentraut writes:
> > On ons, 2011-08-17 at 13:20 -0400, Tom Lane wrote:
> >> It's not immediately apparent to me why we should think that
> >> get_python_lib is less trustworthy than LIBPL; but if someone
> >> can make that case, I don't have any objection to this part of
> >> the patch.
>
> > The issue, at least for me, is that the file isn't necessarily called
> > 'config' anymore. I have
> > /usr/lib/python3.2/config-3.2mu
>
One of the reason, I say that - we do have hard-coded values for the config
directory.
Hence, I used the LIBPL.
>
> Ah, I see.
>
> > LIBPL exists at least as far back as Python 2.2, so its use should be
> > safe.
>
> Yeah, that part of the patch seems sane then.
>
> > Yes, because get_config_vars('LDVERSION') doesn't exist in that version.
> > In theory, it would return '2.7', so everything would fit back together,
> > but LDVERSION doesn't exist before 3.2.
>
Oops - sorry...
I did not know about it..
>
> Could we have the code use 'LDVERSION' if it gets a nonempty result,
> and otherwise fall back to the current scheme? But I guess first we
> need some details as to why the current scheme isn't sufficient.
>
Please find the attached patch as you suggested.
Reason:
- As per my findings, ActiveState Python 3.2 does not provide shared
libraries along with it.
(Though - I am not sure about the earlier version of ActiveState Python)
We can confirm the same using the following command:
${PYTHON} -c "import distutils.sysconfig,string;
print(distutils.sysconfig.get_config_vars('Py_ENABLE_SHARED'))"
Which returns in this case '0'.
And, getting values for the 'python_ldlibrary' and 'python_so' are
'libpython3.2m.a' and '.cpython-32m.so' respectively.
So, the condition - *x"${python_ldlibrary}" != x"${ldlibrary}"* is always
failing, and switching it back to link the old way.
--
Thanks & Regards,
Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company<http://www.enterprisedb.com/>
*http://www.linkedin.com/in/asheshvashi*<http://www.linkedin.com/in/asheshvashi>
>
>regards, tom lane
>
pg9.1beta3_python_v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: Compiling PostgreSQL using ActiveState Python 3.2
Please ignore the previous patch.
Please find the updated patch.
--
Thanks & Regards,
Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company<http://www.enterprisedb.com>
*http://www.linkedin.com/in/asheshvashi*<http://www.linkedin.com/in/asheshvashi>
On Thu, Aug 18, 2011 at 12:57 PM, Ashesh Vashi <
ashesh.va...@enterprisedb.com> wrote:
> On Thu, Aug 18, 2011 at 1:25 AM, Tom Lane wrote:
>
>> Peter Eisentraut writes:
>> > On ons, 2011-08-17 at 13:20 -0400, Tom Lane wrote:
>> >> It's not immediately apparent to me why we should think that
>> >> get_python_lib is less trustworthy than LIBPL; but if someone
>> >> can make that case, I don't have any objection to this part of
>> >> the patch.
>>
>> > The issue, at least for me, is that the file isn't necessarily called
>> > 'config' anymore. I have
>> > /usr/lib/python3.2/config-3.2mu
>>
> One of the reason, I say that - we do have hard-coded values for the config
> directory.
> Hence, I used the LIBPL.
>
>>
>> Ah, I see.
>>
>> > LIBPL exists at least as far back as Python 2.2, so its use should be
>> > safe.
>>
>> Yeah, that part of the patch seems sane then.
>>
>> > Yes, because get_config_vars('LDVERSION') doesn't exist in that version.
>> > In theory, it would return '2.7', so everything would fit back together,
>> > but LDVERSION doesn't exist before 3.2.
>>
> Oops - sorry...
> I did not know about it..
>
>>
>> Could we have the code use 'LDVERSION' if it gets a nonempty result,
>> and otherwise fall back to the current scheme? But I guess first we
>> need some details as to why the current scheme isn't sufficient.
>>
> Please find the attached patch as you suggested.
>
> Reason:
> - As per my findings, ActiveState Python 3.2 does not provide shared
> libraries along with it.
> (Though - I am not sure about the earlier version of ActiveState Python)
> We can confirm the same using the following command:
> ${PYTHON} -c "import distutils.sysconfig,string;
> print(distutils.sysconfig.get_config_vars('Py_ENABLE_SHARED'))"
> Which returns in this case '0'.
>
> And, getting values for the 'python_ldlibrary' and 'python_so' are
> 'libpython3.2m.a' and '.cpython-32m.so' respectively.
> So, the condition - *x"${python_ldlibrary}" != x"${ldlibrary}"* is always
> failing, and switching it back to link the old way.
>
> --
>
> Thanks & Regards,
>
> Ashesh Vashi
> EnterpriseDB INDIA: Enterprise PostgreSQL
> Company<http://www.enterprisedb.com/>
>
>
>
> *http://www.linkedin.com/in/asheshvashi*<http://www.linkedin.com/in/asheshvashi>
>
>
>>
>>regards, tom lane
>>
>
>
pg9.1beta3_python_v3.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PATCH: Compiling PostgreSQL using ActiveState Python 3.2
On Thu, Aug 18, 2011 at 5:25 PM, Peter Eisentraut wrote:
> On tor, 2011-08-18 at 14:51 +0530, Ashesh Vashi wrote:
> > Please ignore the previous patch.
> > Please find the updated patch.
>
> Committed more or less like that.
>
Thanks
>
> In passing I also fixed the build with Python 3 on Windows, which
> apparently never worked before. But I suppose you have been referring
> to the ActiveState Linux build all along.
>
Yes.
--
Thanks & Regards,
Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company<http://www.enterprisedb.com/>
*http://www.linkedin.com/in/asheshvashi*<http://www.linkedin.com/in/asheshvashi>
>
> >
> > --
> >
> > Thanks & Regards,
> >
> > Ashesh Vashi
> > EnterpriseDB INDIA: Enterprise PostgreSQL Company<
> http://www.enterprisedb.com>
> >
> >
> >
> > *http://www.linkedin.com/in/asheshvashi*<
> http://www.linkedin.com/in/asheshvashi>
> >
> >
> >
> > On Thu, Aug 18, 2011 at 12:57 PM, Ashesh Vashi <
> > ashesh.va...@enterprisedb.com> wrote:
> >
> > > On Thu, Aug 18, 2011 at 1:25 AM, Tom Lane wrote:
> > >
> > >> Peter Eisentraut writes:
> > >> > On ons, 2011-08-17 at 13:20 -0400, Tom Lane wrote:
> > >> >> It's not immediately apparent to me why we should think that
> > >> >> get_python_lib is less trustworthy than LIBPL; but if someone
> > >> >> can make that case, I don't have any objection to this part of
> > >> >> the patch.
> > >>
> > >> > The issue, at least for me, is that the file isn't necessarily
> called
> > >> > 'config' anymore. I have
> > >> > /usr/lib/python3.2/config-3.2mu
> > >>
> > > One of the reason, I say that - we do have hard-coded values for the
> config
> > > directory.
> > > Hence, I used the LIBPL.
> > >
> > >>
> > >> Ah, I see.
> > >>
> > >> > LIBPL exists at least as far back as Python 2.2, so its use should
> be
> > >> > safe.
> > >>
> > >> Yeah, that part of the patch seems sane then.
> > >>
> > >> > Yes, because get_config_vars('LDVERSION') doesn't exist in that
> version.
> > >> > In theory, it would return '2.7', so everything would fit back
> together,
> > >> > but LDVERSION doesn't exist before 3.2.
> > >>
> > > Oops - sorry...
> > > I did not know about it..
> > >
> > >>
> > >> Could we have the code use 'LDVERSION' if it gets a nonempty result,
> > >> and otherwise fall back to the current scheme? But I guess first we
> > >> need some details as to why the current scheme isn't sufficient.
> > >>
> > > Please find the attached patch as you suggested.
> > >
> > > Reason:
> > > - As per my findings, ActiveState Python 3.2 does not provide shared
> > > libraries along with it.
> > > (Though - I am not sure about the earlier version of ActiveState
> Python)
> > > We can confirm the same using the following command:
> > > ${PYTHON} -c "import distutils.sysconfig,string;
> > > print(distutils.sysconfig.get_config_vars('Py_ENABLE_SHARED'))"
> > > Which returns in this case '0'.
> > >
> > > And, getting values for the 'python_ldlibrary' and 'python_so' are
> > > 'libpython3.2m.a' and '.cpython-32m.so' respectively.
> > > So, the condition - *x"${python_ldlibrary}" != x"${ldlibrary}"* is
> always
> > > failing, and switching it back to link the old way.
> > >
> > > --
> > >
> > > Thanks & Regards,
> > >
> > > Ashesh Vashi
> > > EnterpriseDB INDIA: Enterprise PostgreSQL Company<
> http://www.enterprisedb.com/>
> > >
> > >
> > >
> > > *http://www.linkedin.com/in/asheshvashi*<
> http://www.linkedin.com/in/asheshvashi>
> > >
> > >
> > >>
> > >>regards, tom lane
> > >>
> > >
> > >
>
>
>
>
Re: [HACKERS] pg_stat directory and pg_stat_statements
On Thu, May 29, 2014 at 8:52 AM, Fujii Masao wrote: > On Thu, May 29, 2014 at 4:55 AM, Tomas Vondra wrote: > > On 28.5.2014 19:52, Fujii Masao wrote: > >> On Thu, May 29, 2014 at 12:37 AM, Peter Geoghegan > wrote: > >>> On Wed, May 28, 2014 at 7:01 AM, Fujii Masao > wrote: > >>>> But pg_stat_statements file is saved under $PGDATA/global yet. > >>>> Is this intentional or just oversight? > >>> > >>> > >>> I think it's an oversight. > >> > >> OK, patch attached. > >> > >> I'm afraid that it's not okay to change the file layout in $PGDATA at > this beta1 > >> stage because that change basically seems to need initdb. Otherwise > something > >> like "no such file or directory" error can happen. But in this case > what we need > >> to change is only the location of the pg_stat_statements permanent > stats file. > >> So, without initdb, the server will not be able to find the > >> pg_stat_statements stats > >> file, but this is not so harmful. Only the problem is that the > >> pg_stat_statements > >> stats which were collected in past would disappear. OTOH, the server > can keep > >> running successfully from then and no critical data will not > >> disappear. Therefore > >> I think we can commit this patch even at beta1. Thought? > > > > For HEAD, probably yes. But what about backpatching 9.3? > > I think No. So we should not backpatch this to 9.3. > Just curious. Will it work in upgrade scenario? -- Thanks & Regards, Ashesh Vashi > > Regards, > > -- > Fujii Masao > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
Re: [HACKERS] pg_stat directory and pg_stat_statements
On Thu, May 29, 2014 at 11:32 AM, Peter Geoghegan wrote: > On Wed, May 28, 2014 at 10:49 PM, Fujii Masao > wrote: > > You're concerned about the scenario using pg_upgrade? > Yeah - I was. > I'm not sure the detail > > of pg_upgrade. But if it doesn't work properly, we should have gotten > > the trouble > > I'm not worried about pg_upgrade, because by design pg_stat_statements > will discard stats files that originated in earlier versions. However, > I don't see a need to change pg_stat_statements to serialize its > statistics to disk in the pg_stat directory before we branch off 9.4. > As you mentioned, it's harmless. > K. I was just curious about the scenario. If it was discarding the stats files that originated in earlier version, It should be ok. -- Thanks & Regards, Ashesh Vashi > > -- > Peter Geoghegan >
