Re: [HACKERS] scram and \password

[Ashesh Vashi]

On Thu, Apr 27, 2017 at 9:57 AM, Michael Paquier <michael.paqu...@gmail.com>
wrote:

> On Thu, Apr 27, 2017 at 1:25 PM, Ashesh Vashi
> <ashesh.va...@enterprisedb.com> 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] scram and \password

[Ashesh Vashi]

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 

Re: [HACKERS] Missing plpgsql.o Symbols on OS X

[Ashesh Vashi]

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 da...@justatheory.com
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] pg_stat directory and pg_stat_statements

[Ashesh Vashi]

On Thu, May 29, 2014 at 11:32 AM, Peter Geoghegan p...@heroku.com wrote:

 On Wed, May 28, 2014 at 10:49 PM, Fujii Masao masao.fu...@gmail.com
 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

Re: [HACKERS] pg_stat directory and pg_stat_statements

[Ashesh Vashi]

On Thu, May 29, 2014 at 8:52 AM, Fujii Masao masao.fu...@gmail.com wrote:

 On Thu, May 29, 2014 at 4:55 AM, Tomas Vondra t...@fuzzy.cz wrote:
  On 28.5.2014 19:52, Fujii Masao wrote:
  On Thu, May 29, 2014 at 12:37 AM, Peter Geoghegan p...@heroku.com
 wrote:
  On Wed, May 28, 2014 at 7:01 AM, Fujii Masao masao.fu...@gmail.com
 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] narwhal and PGDLLIMPORT

[Ashesh Vashi]

On Mon, Feb 3, 2014 at 6:52 AM, Craig Ringer cr...@2ndquadrant.com 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 Companyhttp://www.enterprisedb.com



*http://www.linkedin.com/in/asheshvashi*http://www.linkedin.com/in/asheshvashi

Re: [HACKERS] PATCH: Compiling PostgreSQL using ActiveState Python 3.2

[Ashesh Vashi]

Please ignore the previous patch.
Please find the updated patch.

--

Thanks  Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Companyhttp://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 t...@sss.pgh.pa.us wrote:

 Peter Eisentraut pete...@gmx.net 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 
 Companyhttp://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

[Ashesh Vashi]

On Thu, Aug 18, 2011 at 5:25 PM, Peter Eisentraut pete...@gmx.net 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 Companyhttp://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 t...@sss.pgh.pa.us wrote:
  
   Peter Eisentraut pete...@gmx.net 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] PostgreSQL Core Team

[Ashesh Vashi]

Congrats Magnus!!!
Thanks for the smart work and keep it up...

--
Thanks  Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Companyhttp://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 dp...@postgresql.org 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 Companyhttp://www.enterprisedb.com



*http://www.linkedin.com/in/asheshvashi*http://www.linkedin.com/in/asheshvashi