Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bx7oa-00022W-Oe for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 07:31:01 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bx7oZ-0007IH-17 for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 07:30:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bx7oX-0007I3-H9 for pgadmin-hackers@postgresql.org; Thu, 20 Oct 2016 07:30:57 +0000 Received: from mail-lf0-x234.google.com ([2a00:1450:4010:c07::234]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bx7oS-0000IR-9i for pgadmin-hackers@postgresql.org; Thu, 20 Oct 2016 07:30:56 +0000 Received: by mail-lf0-x234.google.com with SMTP id x79so72638263lff.0 for ; Thu, 20 Oct 2016 00:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ja3Gmif13k9mHT8cIvJsvHANKdElebcNHI+C6dO42Vc=; b=cNptg2LKiGatqLqQuxn8+peajTwf9DPhXrWFeqwDja1V3FhLsPHDQVdNI63KLoUOt8 yOIAUANGnNqhZMbB2oztAHGMOrRMIt7gGDJVZPWo1/8/THrQ5PDIdW02biVgiVYzCyKG qjkpwHylgC/FIwiKZsVt9gmgJAPDfbLr44UHta/hxH+0y0Lr4t0RoYiruIcDUp1GdqEW o09yuTP1Ze6vrQNDSx+y/9nIN96xdq1glXlgcBms2jd9lhy00yTRTRMb1yyFXjbim8fn 8PyK7pd/dYWtsE/zf++IPNxifdi9C0yRkHa9sIt14VmcEwPrwSiYfkwIzYmshoXfOc5V CfKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ja3Gmif13k9mHT8cIvJsvHANKdElebcNHI+C6dO42Vc=; b=FpMRZUbsKw+RE4Zw7q64luxHKcNYCNi0ilVOp9ss57dqHs3SbGMVpX4o6DrbAj32HO dSx+Kci5ozTF2XicZizz41C6UvUg3Mv9AJrTvegjF5xmxworCJcrKKYNIRbqsUotUxuA ERZFSuiK92/frk9tjHMDNs8LEUa7rNBT7hsrZDmju6GgM5t7ZR6y9Y24YB78DpRrWKdm lsE2GjGUwElgx8fLiBsrxHIMRuWUYeqRLCXh0Bzh0/2/5P7dV2uZHDvU30oBgyCxxEqC C47M5qsZeksGDMdt42C5fg9k5PKcpoc2UjyiW8XjlJxTscM0d7jFX0jV/PtM/oEpK2Y8 sWHw== X-Gm-Message-State: AA6/9RneAeazDM//TjY3s4a+zoDFdinVVgp8V5G8FBuW7wF79EhAFiRsk8CrWy69f4RiCvqHBDkr/MJeZ7vLTs38 X-Received: by 10.25.163.132 with SMTP id m126mr8155082lfe.9.1476948650747; Thu, 20 Oct 2016 00:30:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.92.219 with HTTP; Thu, 20 Oct 2016 00:30:49 -0700 (PDT) In-Reply-To: References: From: Fahar Abbas Date: Thu, 20 Oct 2016 12:30:49 +0500 Message-ID: Subject: Re: RM1849: Auto-generating security keys To: Murtuza Zabuawala Cc: Dave Page , Ashesh Vashi , pgadmin-hackers , Josh Berkus , =?UTF-8?B?RGV2cmltIEfDnE5Ew5xa?= , Magnus Hagander , Sandeep Thakkar , Hamid Quddus Akhtar Content-Type: multipart/alternative; boundary=001a11411b1cadff63053f46e7af X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgadmin-hackers Precedence: bulk Sender: pgadmin-hackers-owner@postgresql.org --001a11411b1cadff63053f46e7af Content-Type: text/plain; charset=UTF-8 Murtaza, Once i delete key table from pgAdmin4.db file then i can launch pgAdmin4 with terminal as well as web browser for existing pgAdmin4 setup. In case of fresh setup once we delete key table and apply latest patch following message displayed: python pgAdmin4.py Traceback (most recent call last): File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py", line 1139, in _execute_context context) File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/default.py", line 450, in do_execute cursor.execute(statement, parameters) sqlite3.OperationalError: no such table: keys The above exception was the direct cause of the following exception: Traceback (most recent call last): File "pgAdmin4.py", line 46, in app = create_app() File "/home/fahar/Projects/pgadmin4/web/pgadmin/__init__.py", line 224, in create_app config.CSRF_SESSION_KEY = Keys.query.filter_by(name = 'CSRF_SESSION_KEY').first().value File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/orm/query.py", line 2659, in first ret = list(self[0:1]) File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/orm/query.py", line 2457, in __getitem__ return list(res) File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/orm/query.py", line 2761, in __iter__ return self._execute_and_instances(context) File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/orm/query.py", line 2776, in _execute_and_instances result = conn.execute(querycontext.statement, self._params) File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py", line 914, in execute return meth(self, multiparams, params) File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/sql/elements.py", line 323, in _execute_on_connection return connection._execute_clauseelement(self, multiparams, params) File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py", line 1010, in _execute_clauseelement compiled_sql, distilled_params File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py", line 1146, in _execute_context context) File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py", line 1341, in _handle_dbapi_exception exc_info File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/util/compat.py", line 202, in raise_from_cause reraise(type(exception), exception, tb=exc_tb, cause=cause) File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/util/compat.py", line 185, in reraise raise value.with_traceback(tb) File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py", line 1139, in _execute_context context) File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/default.py", line 450, in do_execute cursor.execute(statement, parameters) sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) no such table: keys [SQL: 'SELECT keys.name AS keys_name, keys.value AS keys_value \nFROM keys \nWHERE keys.name = ?\n LIMIT ? OFFSET ?'] [parameters: ('CSRF_SESSION_KEY', 1, 0)] On Thu, Oct 20, 2016 at 11:00 AM, Murtuza Zabuawala < murtuza.zabuawala@enterprisedb.com> wrote: > Could you delete 'keys' table from pgadmin4.db file & try again? > > -- > Regards, > Murtuza Zabuawala > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > On Thu, Oct 20, 2016 at 11:26 AM, Fahar Abbas < > fahar.abbas@enterprisedb.com> wrote: > >> Murtaza, >> >> I have applied this patch and there is no success on new pgAdmin4 setup >> as well as existing pgAdmin4 setup. >> >> On Thu, Oct 20, 2016 at 10:45 AM, Murtuza Zabuawala < >> murtuza.zabuawala@enterprisedb.com> wrote: >> >>> Hi, >>> >>> PFA patch to fix the issue for Pyhton3. >>> RM#1849 >>> >>> -- >>> Regards, >>> Murtuza Zabuawala >>> EnterpriseDB: http://www.enterprisedb.com >>> The Enterprise PostgreSQL Company >>> >>> On Thu, Oct 20, 2016 at 11:03 AM, Fahar Abbas < >>> fahar.abbas@enterprisedb.com> wrote: >>> >>>> Hi Dave, >>>> >>>> I have reopened following RM: >>>> ================================ >>>> https://redmine.postgresql.org/issues/1849 >>>> >>>> On Wed, Oct 19, 2016 at 6:04 PM, Dave Page wrote: >>>> >>>>> Patch applied. >>>>> >>>>> On Wed, Oct 19, 2016 at 11:55 AM, Ashesh Vashi < >>>>> ashesh.vashi@enterprisedb.com> wrote: >>>>> >>>>>> Hi Fahar, >>>>>> >>>>>> Please log the case on redmine. >>>>>> Please find the attached patch, please apply it locally, and test it. >>>>>> >>>>>> And, please update the case, and this mail chain accordingly. >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks & Regards, >>>>>> >>>>>> Ashesh Vashi >>>>>> EnterpriseDB INDIA: Enterprise PostgreSQL Company >>>>>> >>>>>> >>>>>> >>>>>> *http://www.linkedin.com/in/asheshvashi* >>>>>> >>>>>> >>>>>> On Wed, Oct 19, 2016 at 3:47 PM, Fahar Abbas < >>>>>> fahar.abbas@enterprisedb.com> wrote: >>>>>> >>>>>>> Here is the output of if we copy config_local.py and execute python >>>>>>> setup.py >>>>>>> pgAdmin 4 - Application Initialisation >>>>>>> ====================================== >>>>>>> >>>>>>> >>>>>>> The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' >>>>>>> does not exist. >>>>>>> Entering initial setup mode... >>>>>>> NOTE: Configuring authentication for SERVER mode. >>>>>>> >>>>>>> >>>>>>> Enter the email address and password to use for the initial >>>>>>> pgAdmin user account: >>>>>>> >>>>>>> Email address: fahar.abbas@enterprisedb.com >>>>>>> Password: >>>>>>> Retype password: >>>>>>> Traceback (most recent call last): >>>>>>> File "setup.py", line 449, in >>>>>>> do_setup(app) >>>>>>> File "setup.py", line 96, in do_setup >>>>>>> password = encrypt_password(p1) >>>>>>> File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", >>>>>>> line 150, in encrypt_password >>>>>>> signed = get_hmac(password).decode('ascii') >>>>>>> File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", >>>>>>> line 108, in get_hmac >>>>>>> 'set to "%s"' % _security.password_hash) >>>>>>> RuntimeError: The configuration value `SECURITY_PASSWORD_SALT` must >>>>>>> not be None when the value of `SECURITY_PASSWORD_HASH` is set to >>>>>>> "pbkdf2_sha512" >>>>>>> python setup.py >>>>>>> pgAdmin 4 - Application Initialisation >>>>>>> ====================================== >>>>>>> >>>>>>> User can not do any setup for web based now. >>>>>>> >>>>>>> >>>>>>> The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' >>>>>>> does not exist. >>>>>>> Entering initial setup mode... >>>>>>> NOTE: Configuring authentication for SERVER mode. >>>>>>> >>>>>>> >>>>>>> Enter the email address and password to use for the initial >>>>>>> pgAdmin user account: >>>>>>> >>>>>>> Email address: fahar.abbas@enterprisedb.com >>>>>>> Password: >>>>>>> Retype password: >>>>>>> Traceback (most recent call last): >>>>>>> File "setup.py", line 449, in >>>>>>> do_setup(app) >>>>>>> File "setup.py", line 96, in do_setup >>>>>>> password = encrypt_password(p1) >>>>>>> File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", >>>>>>> line 150, in encrypt_password >>>>>>> signed = get_hmac(password).decode('ascii') >>>>>>> File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", >>>>>>> line 108, in get_hmac >>>>>>> 'set to "%s"' % _security.password_hash) >>>>>>> RuntimeError: The configuration value `SECURITY_PASSWORD_SALT` must >>>>>>> not be None when the value of `SECURITY_PASSWORD_HASH` is set to >>>>>>> "pbkdf2_sha512" >>>>>>> >>>>>>> On Wed, Oct 19, 2016 at 3:03 PM, Fahar Abbas < >>>>>>> fahar.abbas@enterprisedb.com> wrote: >>>>>>> >>>>>>>> Dave, >>>>>>>> >>>>>>>> Testing Environment >>>>>>>> >>>>>>>> Ubuntu 16.04 Linux 64: >>>>>>>> -------------------------------- >>>>>>>> >>>>>>>> pg-AdminIV Development Environment Setup for Ubuntu : >>>>>>>> >>>>>>>> >>>>>>>> 1) Install GIT >>>>>>>> >>>>>>>> sudo apt-get install git >>>>>>>> >>>>>>>> 2) Install pip3 >>>>>>>> >>>>>>>> sudo apt-get install python3-pip >>>>>>>> >>>>>>>> 3) Install virtualenv >>>>>>>> >>>>>>>> sudo pip3 install virtualenv >>>>>>>> >>>>>>>> 4) install below dependency as it is required for psycopg2 & >>>>>>>> pycrypto module >>>>>>>> >>>>>>>> sudo apt-get install libpq-dev >>>>>>>> >>>>>>>> sudo apt-get install python3-dev >>>>>>>> >>>>>>>> 5) Create virtual environment >>>>>>>> >>>>>>>> virtualenv -p python3 venv >>>>>>>> >>>>>>>> 6) Create mkdir Projects >>>>>>>> >>>>>>>> 7) Clone git repo in Projects >>>>>>>> >>>>>>>> git clone http://git.postgresql.org/git/pgadmin4.git >>>>>>>> >>>>>>>> 8) activate virtual environment >>>>>>>> >>>>>>>> source venv/bin/activate >>>>>>>> >>>>>>>> 9) Install modules >>>>>>>> >>>>>>>> pip3 install -r requirements_py3.txt >>>>>>>> >>>>>>>> *10) Edit the config.py file to config_local.py resides in >>>>>>>> Projects\pgAdmin4\web * >>>>>>>> >>>>>>>> 11)Now run setup.py file (\Projects\pgAdmin4\web) >>>>>>>> python setup.py >>>>>>>> >>>>>>>> If user does not create config_local.py and do Python setup.py for >>>>>>>> new Development then SECURITY_PASSWORD_SALT message is also displayed: >>>>>>>> >>>>>>>> Here is the output: >>>>>>>> ------------------------- >>>>>>>> >>>>>>>> python setup.py >>>>>>>> pgAdmin 4 - Application Initialisation >>>>>>>> ====================================== >>>>>>>> >>>>>>>> >>>>>>>> The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' >>>>>>>> does not exist. >>>>>>>> Entering initial setup mode... >>>>>>>> NOTE: Configuring authentication for SERVER mode. >>>>>>>> >>>>>>>> >>>>>>>> Enter the email address and password to use for the initial >>>>>>>> pgAdmin user account: >>>>>>>> >>>>>>>> Email address: fahar.abbas@enterprisedb.com >>>>>>>> Password: >>>>>>>> Retype password: >>>>>>>> Traceback (most recent call last): >>>>>>>> File "setup.py", line 449, in >>>>>>>> do_setup(app) >>>>>>>> File "setup.py", line 96, in do_setup >>>>>>>> password = encrypt_password(p1) >>>>>>>> File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", >>>>>>>> line 150, in encrypt_password >>>>>>>> signed = get_hmac(password).decode('ascii') >>>>>>>> File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py", >>>>>>>> line 108, in get_hmac >>>>>>>> 'set to "%s"' % _security.password_hash) >>>>>>>> RuntimeError: The configuration value `SECURITY_PASSWORD_SALT` must >>>>>>>> not be None when the value of `SECURITY_PASSWORD_HASH` is set to >>>>>>>> "pbkdf2_sha512" >>>>>>>> (venv) fahar@fahar-virtual-machine:~/Projects/pgadmin4/web$ >>>>>>>> >>>>>>>> >>>>>>>> Is this expected? >>>>>>>> >>>>>>>> On Wed, Oct 19, 2016 at 1:37 PM, Fahar Abbas < >>>>>>>> fahar.abbas@enterprisedb.com> wrote: >>>>>>>> >>>>>>>>> Sure, >>>>>>>>> >>>>>>>>> Will test this thoroughly after complete investigation. >>>>>>>>> >>>>>>>>> Kind Regards, >>>>>>>>> >>>>>>>>> On Wed, Oct 19, 2016 at 1:27 PM, Dave Page >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Patch applied. >>>>>>>>>> >>>>>>>>>> Fahar, can you please test this thoroughly in desktop and server >>>>>>>>>> modes, with both fresh and upgraded installations? >>>>>>>>>> >>>>>>>>>> https://redmine.postgresql.org/issues/1849 >>>>>>>>>> >>>>>>>>>> Packagers: This change means that packages are no longer forced >>>>>>>>>> to create a config_local.py file, and there is no longer any need to >>>>>>>>>> explicitly set SECURITY_PASSWORD_SALT, SECURITY_KEY >>>>>>>>>> and CSRF_SESSION_KEY in the config (in fact, they should be removed for new >>>>>>>>>> installations, if you have included them in 1.0) >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Oct 19, 2016 at 6:46 AM, Ashesh Vashi < >>>>>>>>>> ashesh.vashi@enterprisedb.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Dave, >>>>>>>>>>> >>>>>>>>>>> On Sat, Oct 15, 2016 at 8:02 AM, Dave Page >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Friday, October 14, 2016, Dave Page >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi >>>>>>>>>>>>> >>>>>>>>>>>>> On Thursday, October 13, 2016, Ashesh Vashi < >>>>>>>>>>>>> ashesh.vashi@enterprisedb.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Dave, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Oct 11, 2016 at 9:10 PM, Dave Page >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Ashesh, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can you please review the attached patch, and apply if >>>>>>>>>>>>>>> you're happy with it? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Overall the patch looked good to me. >>>>>>>>>>>>>> But - I encounter an issue in 'web' mode, which wont happen >>>>>>>>>>>>>> with 'runtime'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Steps for reproduction on existing pgAdmin 4 environment with >>>>>>>>>>>>>> 'web' mode. >>>>>>>>>>>>>> - Apply the patch >>>>>>>>>>>>>> - Start the pgAdmin4 application (stand alone application). >>>>>>>>>>>>>> - Open pgAdmin home page. >>>>>>>>>>>>>> - Log out (if already login). >>>>>>>>>>>>>> >>>>>>>>>>>>>> And, you will see an exception. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have figure out the issue with the patch. >>>>>>>>>>>>>> We were setting the SECURITY_PASSWORD_SALT, after >>>>>>>>>>>>>> initializing the Security object. >>>>>>>>>>>>>> Hence - it could not set the SECURITY_KEY, and >>>>>>>>>>>>>> SECURITY_PASSWORD_SALT properly. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hmm. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I had moved the Security object initialization after fetching >>>>>>>>>>>>>> these configurations from the database. >>>>>>>>>>>>>> I have attached a addon patch for the same. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> OK, thanks. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now - I run into another issue. >>>>>>>>>>>>>> Because - the existing password was hashed using the old >>>>>>>>>>>>>> SECURITY_PASSWORD_SALT, I am no more able to login to pgAdmin 4. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think - we need to think about different strategy for >>>>>>>>>>>>>> upgrading the configuration file in the 'web' mode. >>>>>>>>>>>>>> I was thinking - we can store the existing security >>>>>>>>>>>>>> configurations in the database during upgrade process in 'web' mode. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> My concern with that is that we'll likely be storing the >>>>>>>>>>>>> default config values in many cases, thus for those users, perpetuating the >>>>>>>>>>>>> problem. >>>>>>>>>>>>> >>>>>>>>>>>>> I guess what we need to do is re-encrypt the password during >>>>>>>>>>>>> the upgrade - however, that makes me think; we then have both the key and >>>>>>>>>>>>> the encrypted passwords in the same database which is clearly not a good >>>>>>>>>>>>> idea. Sigh... Needs more thought. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> OK, so I've been thinking about this and experimenting for a >>>>>>>>>>>> couple of hours, as well as annoying the crap out of Magnus by thinking out >>>>>>>>>>>> loud in his general direction, and it looks like this isn't a major problem >>>>>>>>>>>> as from what I can see, SECURITY_PASSWORD_SALT is (aside from really being >>>>>>>>>>>> a key not a salt) not the only salting that's done. >>>>>>>>>>>> >>>>>>>>>>>> It looks like it's used system-wide as the key to generate an >>>>>>>>>>>> HMAC of the users password, which is then passed to passlib which salts and >>>>>>>>>>>> hashes it. I did some testing, and found that two users with the same >>>>>>>>>>>> password end up with different hashes in the database, so clearly there is >>>>>>>>>>>> also per-user salting happening. I also created two users, then dropped the >>>>>>>>>>>> database and created the same user accounts with the same passwords again, >>>>>>>>>>>> and found that the resulting hashes were different in both databases - thus >>>>>>>>>>>> there is something else ensuring the hashes are unique across different >>>>>>>>>>>> installations/databases. >>>>>>>>>>>> >>>>>>>>>>>> So, I believe we can do as you suggest and migrate existing >>>>>>>>>>>> values for SECURITY_PASSWORD_SALT, given that there's clearly some other >>>>>>>>>>>> per user and per installation/database salting going on anyway. New >>>>>>>>>>>> installations can have the random value for SECURITY_PASSWORD_SALT. >>>>>>>>>>>> >>>>>>>>>>> We do not need to generate the random SECURITY_PASSWORD_SALT >>>>>>>>>>> during upgrade mode, which was wrong added in my addon patch. >>>>>>>>>>> >>>>>>>>>>> Please find the updated patch. >>>>>>>>>>> >>>>>>>>>>> Otherwise - looks good to me. >>>>>>>>>>> Please commit the new patch (if you're ok with the change). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> Thanks & Regards, >>>>>>>>>>> >>>>>>>>>>> Ashesh Vashi >>>>>>>>>>> EnterpriseDB INDIA: Enterprise PostgreSQL Company >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *http://www.linkedin.com/in/asheshvashi* >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I don't believe SECURITY_KEY and CSRF_SESSION_KEY are issues >>>>>>>>>>>> either, as they're used for purposes that are essentially ephemeral, and >>>>>>>>>>>> thus can be changed during an upgrade. >>>>>>>>>>>> >>>>>>>>>>>> Adding Magnus as I'd appreciate any thoughts he may have. >>>>>>>>>>>> >>>>>>>>>>>> Patch attached - please review (Ashesh, but others too would be >>>>>>>>>>>> appreciated)! >>>>>>>>>>>> >>>>>>>>>>>> Thanks. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Dave Page >>>>>>>>>>>> Blog: http://pgsnake.blogspot.com >>>>>>>>>>>> Twitter: @pgsnake >>>>>>>>>>>> >>>>>>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com >>>>>>>>>>>> The Enterprise PostgreSQL Company >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Dave Page >>>>>>>>>> Blog: http://pgsnake.blogspot.com >>>>>>>>>> Twitter: @pgsnake >>>>>>>>>> >>>>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com >>>>>>>>>> The Enterprise PostgreSQL Company >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Syed Fahar Abbas >>>>>>>>> Quality Management Group >>>>>>>>> >>>>>>>>> EnterpriseDB Corporation >>>>>>>>> Phone Office: +92-51-835-8874 >>>>>>>>> Phone Direct: +92-51-8466803 >>>>>>>>> Mobile: +92-333-5409707 >>>>>>>>> Skype ID: syed.fahar.abbas >>>>>>>>> Website: www.enterprisedb.com >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Syed Fahar Abbas >>>>>>>> Quality Management Group >>>>>>>> >>>>>>>> EnterpriseDB Corporation >>>>>>>> Phone Office: +92-51-835-8874 >>>>>>>> Phone Direct: +92-51-8466803 >>>>>>>> Mobile: +92-333-5409707 >>>>>>>> Skype ID: syed.fahar.abbas >>>>>>>> Website: www.enterprisedb.com >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Syed Fahar Abbas >>>>>>> Quality Management Group >>>>>>> >>>>>>> EnterpriseDB Corporation >>>>>>> Phone Office: +92-51-835-8874 >>>>>>> Phone Direct: +92-51-8466803 >>>>>>> Mobile: +92-333-5409707 >>>>>>> Skype ID: syed.fahar.abbas >>>>>>> Website: www.enterprisedb.com >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Dave Page >>>>> Blog: http://pgsnake.blogspot.com >>>>> Twitter: @pgsnake >>>>> >>>>> EnterpriseDB UK: http://www.enterprisedb.com >>>>> The Enterprise PostgreSQL Company >>>>> >>>> >>>> >>>> >>>> -- >>>> Syed Fahar Abbas >>>> Quality Management Group >>>> >>>> EnterpriseDB Corporation >>>> Phone Office: +92-51-835-8874 >>>> Phone Direct: +92-51-8466803 >>>> Mobile: +92-333-5409707 >>>> Skype ID: syed.fahar.abbas >>>> Website: www.enterprisedb.com >>>> >>> >>> >> >> >> -- >> Syed Fahar Abbas >> Quality Management Group >> >> EnterpriseDB Corporation >> Phone Office: +92-51-835-8874 >> Phone Direct: +92-51-8466803 >> Mobile: +92-333-5409707 >> Skype ID: syed.fahar.abbas >> Website: www.enterprisedb.com >> > > -- Syed Fahar Abbas Quality Management Group EnterpriseDB Corporation Phone Office: +92-51-835-8874 Phone Direct: +92-51-8466803 Mobile: +92-333-5409707 Skype ID: syed.fahar.abbas Website: www.enterprisedb.com --001a11411b1cadff63053f46e7af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Murtaza,

Once i delete key table fr= om pgAdmin4.db file then i can launch pgAdmin4 with terminal as well as web= browser for existing pgAdmin4 setup.


In case of fresh set= up once we delete key table and apply latest patch following message displa= yed:

python pgAdmin4.py
Traceback (most recent call last):
= =C2=A0 File "/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/e= ngine/base.py", line 1139, in _execute_context
=C2=A0=C2=A0=C2=A0 c= ontext)
=C2=A0 File "/home/fahar/venv/lib/python3.5/site-packages/s= qlalchemy/engine/default.py", line 450, in do_execute
=C2=A0=C2=A0= =C2=A0 cursor.execute(statement, parameters)
sqlite3.OperationalError: n= o such table: keys

The above exception was the direct cause of the f= ollowing exception:

Traceback (most recent call last):
=C2=A0 Fil= e "pgAdmin4.py", line 46, in <module>
=C2=A0=C2=A0=C2=A0= app =3D create_app()
=C2=A0 File "/home/fahar/Projects/pgadmin4/we= b/pgadmin/__init__.py", line 224, in create_app
=C2=A0=C2=A0=C2=A0 = config.CSRF_SESSION_KEY =3D Keys.query.filter_by(name =3D 'CSRF_SESSION= _KEY').first().value
=C2=A0 File "/home/fahar/venv/lib/python3.= 5/site-packages/sqlalchemy/orm/query.py", line 2659, in first
=C2= =A0=C2=A0=C2=A0 ret =3D list(self[0:1])
=C2=A0 File "/home/fahar/ve= nv/lib/python3.5/site-packages/sqlalchemy/orm/query.py", line 2457, in= __getitem__
=C2=A0=C2=A0=C2=A0 return list(res)
=C2=A0 File "/h= ome/fahar/venv/lib/python3.5/site-packages/sqlalchemy/orm/query.py", l= ine 2761, in __iter__
=C2=A0=C2=A0=C2=A0 return self._execute_and_instan= ces(context)
=C2=A0 File "/home/fahar/venv/lib/python3.5/site-packa= ges/sqlalchemy/orm/query.py", line 2776, in _execute_and_instances
= =C2=A0=C2=A0=C2=A0 result =3D conn.execute(querycontext.statement, self._pa= rams)
=C2=A0 File "/home/fahar/venv/lib/python3.5/site-packages/sql= alchemy/engine/base.py", line 914, in execute
=C2=A0=C2=A0=C2=A0 re= turn meth(self, multiparams, params)
=C2=A0 File "/home/fahar/venv/= lib/python3.5/site-packages/sqlalchemy/sql/elements.py", line 323, in = _execute_on_connection
=C2=A0=C2=A0=C2=A0 return connection._execute_cla= useelement(self, multiparams, params)
=C2=A0 File "/home/fahar/venv= /lib/python3.5/site-packages/sqlalchemy/engine/base.py", line 1010, in= _execute_clauseelement
=C2=A0=C2=A0=C2=A0 compiled_sql, distilled_param= s
=C2=A0 File "/home/fahar/venv/lib/python3.5/site-packages/sqlalch= emy/engine/base.py", line 1146, in _execute_context
=C2=A0=C2=A0=C2= =A0 context)
=C2=A0 File "/home/fahar/venv/lib/python3.5/site-packa= ges/sqlalchemy/engine/base.py", line 1341, in _handle_dbapi_exception<= br>=C2=A0=C2=A0=C2=A0 exc_info
=C2=A0 File "/home/fahar/venv/lib/py= thon3.5/site-packages/sqlalchemy/util/compat.py", line 202, in raise_f= rom_cause
=C2=A0=C2=A0=C2=A0 reraise(type(exception), exception, tb=3Dex= c_tb, cause=3Dcause)
=C2=A0 File "/home/fahar/venv/lib/python3.5/si= te-packages/sqlalchemy/util/compat.py", line 185, in reraise
=C2=A0= =C2=A0=C2=A0 raise value.with_traceback(tb)
=C2=A0 File "/home/faha= r/venv/lib/python3.5/site-packages/sqlalchemy/engine/base.py", line 11= 39, in _execute_context
=C2=A0=C2=A0=C2=A0 context)
=C2=A0 File "= ;/home/fahar/venv/lib/python3.5/site-packages/sqlalchemy/engine/default.py&= quot;, line 450, in do_execute
=C2=A0=C2=A0=C2=A0 cursor.execute(stateme= nt, parameters)
sqlalchemy.exc.OperationalError: (sqlite3.OperationalErr= or) no such table: keys [SQL: 'SELECT keys= .name AS keys_name, keys.value AS keys_value \nFROM keys \nWHERE keys.name =3D ?\n LIMIT ? OFFSET ?'] [parame= ters: ('CSRF_SESSION_KEY', 1, 0)]


On Thu, Oct 20, 2016 at 11:00 AM, Mur= tuza Zabuawala <murtuza.zabuawala@enterprisedb.com>= ; wrote:
Could yo= u delete 'keys' table from pgadmin4.db file & try again?=C2=A0<= /div>

--
Regards,<= /font>
Murtuza Zabuawala
<= span style=3D"color:rgb(136,136,136)">EnterpriseDB:=C2=A0http://www.enterprisedb.com
The Enterprise = PostgreSQL Company

On Thu, Oct 20= , 2016 at 11:26 AM, Fahar Abbas <fahar.abbas@enterprisedb.com> wrote:
Murtaza,

I have applied this patch and there is no success o= n new pgAdmin4 setup as well as existing pgAdmin4 setup.

On Thu, Oct 20, 2016 at 10= :45 AM, Murtuza Zabuawala <murtuza.zabuawala@enterprised<= wbr>b.com> wrote:
Hi,

PFA patch to fix the issue for Pyhton3.
RM#1849

--
Regards,
Murtuza Zabuawal= a
EnterpriseDB:=C2=A0http:/= /www.enterprisedb.com
The Enterprise PostgreSQL Company
=

On Thu, Oct 20, 2016 at 11:03 AM, Fahar Abba= s <fahar.abbas@enterprisedb.com> wrote:
Hi Dave,

I have reopened f= ollowing RM:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
https://redmine.postgresql.or= g/issues/1849

On Wed, Oct 19, 2016 at 6:04 PM, Dave Page <dpage@pgadmin= .org> wrote:
Patch applied.

On Wed, O= ct 19, 2016 at 11:55 AM, Ashesh Vashi <ashesh.vashi@enterprise= db.com> wrote:
Hi Fahar,

Please log the case on redmine= .
Please find the attached patch, please apply it locally, and test it.=

And, please update the case, and this mail chain = accordingly.

=

--

Thanks & Regards= ,

Ashesh Vashi
EnterpriseDB INDIA: = Enterprise Postgr= eSQL Company

<= br>

<= a href=3D"http://www.linkedin.com/in/asheshvashi" target=3D"_blank">http= ://www.linkedin.com/in/asheshvashi


On Wed, Oct 19, 2016 at 3:47 PM, Fahar Abbas <= fahar.abbas@enterprisedb.com> wrote:
Here is the output of if we copy config_loc= al.py and execute python setup.py
pgAdmin 4 - Application Initiali= sation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


The con= figuration database - '/home/fahar/.pgadmin/pgadmin4.db' does = not exist.
Entering initial setup mode...
NOTE: Configuring authentic= ation for SERVER mode.


=C2=A0=C2=A0=C2=A0 Enter the email addres= s and password to use for the initial pgAdmin user=C2=A0=C2=A0=C2=A0=C2=A0 = account:

Email address: fahar.abbas@enterprisedb.com
Password:
Ret= ype password:
Traceback (most recent call last):
=C2=A0 File "se= tup.py", line 449, in <module>
=C2=A0=C2=A0=C2=A0 do_setup(ap= p)
=C2=A0 File "setup.py", line 96, in do_setup
=C2=A0=C2= =A0=C2=A0 password =3D encrypt_password(p1)
=C2=A0 File "/home/faha= r/venv/lib/python3.5/site-packages/flask_security/utils.py",= line 150, in encrypt_password
=C2=A0=C2=A0=C2=A0 signed =3D get_hmac(pa= ssword).decode('ascii')
=C2=A0 File "/home/fahar/venv/= lib/python3.5/site-packages/flask_security/utils.py", line 1= 08, in get_hmac
=C2=A0=C2=A0=C2=A0 'set to "%s"' % _se= curity.password_hash)
RuntimeError: The configuration value `SECURITY_PA= SSWORD_SALT` must not be None when the value of `SECURITY_PASSWORD_HASH` is= set to "pbkdf2_sha512"
python setup.py
pgAdmin 4 - Applica= tion Initialisation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
User can not do any setup for web based now.

The configuration database - '/home/fahar/.pgadmin/pgadmin4.= db' does not exist.
Entering initial setup mode...
NOTE: Configur= ing authentication for SERVER mode.


=C2=A0=C2=A0=C2=A0 Enter the= email address and password to use for the initial pgAdmin user=C2=A0=C2=A0= =C2=A0=C2=A0 account:

Email address: fahar.abbas@enterprisedb.com
Pass= word:
Retype password:
Traceback (most recent call last):
=C2=A0 = File "setup.py", line 449, in <module>
=C2=A0=C2=A0=C2= =A0 do_setup(app)
=C2=A0 File "setup.py", line 96, in do_setup=
=C2=A0=C2=A0=C2=A0 password =3D encrypt_password(p1)
=C2=A0 File &qu= ot;/home/fahar/venv/lib/python3.5/site-packages/flask_security/ut= ils.py", line 150, in encrypt_password
=C2=A0=C2=A0=C2=A0 signed = =3D get_hmac(password).decode('ascii')
=C2=A0 File "/h= ome/fahar/venv/lib/python3.5/site-packages/flask_security/utils.p= y", line 108, in get_hmac
=C2=A0=C2=A0=C2=A0 'set to "%s&q= uot;' % _security.password_hash)
RuntimeError: The configuration val= ue `SECURITY_PASSWORD_SALT` must not be None when the value of `SECURITY_PA= SSWORD_HASH` is set to "pbkdf2_sha512"

On Wed, Oct 19, 2016 at 3= :03 PM, Fahar Abbas <fahar.abbas@enterprisedb.com> wrote:
Dave,=

Testing Environment
=C2=A0
Ubuntu 16.0= 4 Linux 64:
--------------------------------

pg-AdminIV Development Environment Setup for Ubuntu=C2=A0 :


1) Install GIT

sudo apt-get install git

2) Install pip3

sudo apt-get install python3-pip

3) Install vir= tualenv

sudo= pip3 install virtualenv

4) install below dependency as it is required for psycopg2 &am= p; pycrypto module

sudo apt-get install libpq-dev

sudo apt-get install python3-dev

5) Create virtual environme= nt

virtualen= v -p python3 venv

6) Cre= ate mkdir Projects

7) Clone git repo in Projects

git clone http://git.postgresql.org/git/pgadmin4.git<= /a>

8) activate vir= tual environment

source venv/bin/activate

9) Install modules

pip3 install -r requirements_py3.txt

10) Edit the config.py file to config_local.py =C2=A0resides in Pro= jects\pgAdmin4\web=C2=A0=C2=A0

11)Now r= un setup.= py file =C2=A0(\Projects\pgAdmin4\web)


If user= does not create config_local.py and do Python setup.py for new Development= then SECURITY_PASSWORD_SALT message is also displayed:


python se= tup.py
pgAdmin 4 - Application Initialisation
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D


The configuration database - '/home= /fahar/.pgadmin/pgadmin4.db' does not exist.
Entering initial s= etup mode...
NOTE: Configuring authentication for SERVER mode.

=C2=A0=C2=A0=C2=A0 Enter the email address and password to use for the in= itial pgAdmin user=C2=A0=C2=A0=C2=A0=C2=A0 account:

Email address: <= a href=3D"mailto:fahar.abbas@enterprisedb.com" target=3D"_blank">fahar.abba= s@enterprisedb.com
Password:
Retype password:
Traceback (most= recent call last):
=C2=A0 File "setup.py", line 449, in <m= odule>
=C2=A0=C2=A0=C2=A0 do_setup(app)
=C2=A0 File "setup.py= ", line 96, in do_setup
=C2=A0=C2=A0=C2=A0 password =3D encrypt_pas= sword(p1)
=C2=A0 File "/home/fahar/venv/lib/python3.5/site-pac= kages/flask_security/utils.py", line 150, in encrypt_password
= =C2=A0=C2=A0=C2=A0 signed =3D get_hmac(password).decode('ascii'= ;)
=C2=A0 File "/home/fahar/venv/lib/python3.5/site-packages/f= lask_security/utils.py", line 108, in get_hmac
=C2=A0=C2=A0=C2= =A0 'set to "%s"' % _security.password_hash)
RuntimeEr= ror: The configuration value `SECURITY_PASSWORD_SALT` must not be None when= the value of `SECURITY_PASSWORD_HASH` is set to "pbkdf2_sha512"<= br>(venv) fahar@fahar-virtual-machine:~/Projects/pgadmin4/web$

Is t= his expected?

On Wed, Oct 19, 2016 at 1:37 PM, Fahar Abbas <= span dir=3D"ltr"><fahar.abbas@enterprisedb.com> wrote:
Sure,

Will te= st this thoroughly after complete investigation.

Kind Regards,=

On Wed, Oct 19, 2016 at 1:27 PM, Dave = Page <dpage@pgadmin.org> wrote:
Patch applied.

Fahar, can you ple= ase test this thoroughly in desktop and server modes, with both fresh and u= pgraded installations?


Packagers: This change mean= s that packages are no longer forced to create a config_local.py file, and = there is no longer any need to explicitly set=C2=A0SECURITY_PASSWORD_SALT,=C2=A0SECURITY_KEY and=C2=A0CSRF_SESSION_KEY in the config (in fact, they= should be removed for new installations, if you have included them in 1.0)=

Thanks.


On Wed, Oct 19, 2016 at 6:46 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
Hi Dave,

<= /div>
On Sat, Oct 15, 2016 at 8:02 AM, Dave Page <dpage@pgadmin.org> wrote:
Hi


On Friday, October 14, 2016, = Dave Page <dpage@= pgadmin.org> wrote:
Hi

On Thursday, October 13, 2016, Ashesh Vashi <ashesh.va= shi@enterprisedb.com> wrote:
Hi Dave,

On Tue, Oct 11, 2016 at 9:10 PM, Dave= Page <dpage@pgadmin.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Hi Ashesh,

<= div>Can you please review the attached patch, and apply if you're happy= with it?
Overall the patch looked good to me.
=
But - I encounter an issue in 'web' mode, which wont happen wi= th 'runtime'.

Steps for reproduction on ex= isting pgAdmin 4 environment with 'web' mode.
- Apply the= patch
- Start the pgAdmin4 application (stand alone application)= .
- Open pgAdmin home page.
- Log out (if already login= ).

And, you will see an exception.

<= /div>
I have figure out the issue with the patch.
We were set= ting the SECURITY_PASSWORD_SALT, after initializing the Security object.
Hence - it could not set the SECURITY_KEY, and SECURITY_PASSWORD_SA= LT properly.

Hmm.
=C2=A0
I had moved the Security object initialization after fetching t= hese configurations from the database.
I have attached a addon pa= tch for the same.

O= K, thanks.
=C2=A0

Now - I run into another issue.
Because -= the existing password was hashed using the old SECURITY_PASSWORD_SALT, I a= m no more able to login to pgAdmin 4.

I think - we= need to think about different strategy for upgrading the configuration fil= e in the 'web' mode.
I was thinking - we can store the ex= isting security configurations in the database during upgrade process in &#= 39;web' mode.

M= y concern with that is that we'll likely be storing the default config = values in many cases, thus for those users, perpetuating the problem.
=

I guess what we need to do is re-encrypt the password d= uring the upgrade - however, that makes me think; we then have both the key= and the encrypted passwords in the same database which is clearly not a go= od idea. Sigh... Needs more thought.=C2=A0

OK, so I've been thinking about this and experimentin= g for a couple of hours, as well as annoying the crap out of Magnus by thin= king out loud in his general direction, and it looks like this isn't a = major problem as from what I can see, =C2=A0SECURITY_PASSWORD_SALT is (asid= e from really being a key not a salt) not the only salting that's done.= =C2=A0

It looks like it's used system-wide as = the key to generate an HMAC of the users password, which is then passed to = passlib which salts and hashes it. I did some testing, and found that two u= sers with the same password end up with different hashes in the database, s= o clearly there is also per-user salting happening. I also created two user= s, then dropped the database and created the same user accounts with the sa= me passwords again, and found that the resulting hashes were different in b= oth databases - thus there is something else ensuring the hashes are unique= across different installations/databases.

So, I b= elieve we can do as you suggest and migrate existing values for SECURITY_PA= SSWORD_SALT, given that there's clearly some other per user and per ins= tallation/database salting going on anyway. New installations can have the = random value for SECURITY_PASSWORD_SALT.
We do not need to generate the random SECURITY_PASSWORD_SALT during upgrad= e mode, which was wrong added in my addon patch.

P= lease find the updated patch.

Otherwise - looks go= od to me.
Please commit the new patch (if you're ok with the = change).


--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA:=C2=A0<= a href=3D"http://www.enterprisedb.com/" target=3D"_blank">Enterprise Postgr= eSQL Company



I don't believe SECURITY_KEY and=C2=A0CSRF_SESSION_KEY = are issues either, as they're used for purposes that are essentially ep= hemeral, and thus can be changed during an upgrade.

Adding Magnus as I'd appreciate any thoughts he may have.
<= br>
Patch attached - please review (Ashesh, but others too would = be appreciated)!

Thanks.


-- =
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

Enterpris= eDB UK: http://ww= w.enterprisedb.com
The Enterprise PostgreSQL Company





--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

Ent= erpriseDB UK: htt= p://www.enterprisedb.com
The Enterprise PostgreSQL Company



--
Syed Fahar Abbas
Qualit= y Management Group

EnterpriseDB Corporation
Phone Office: += 92-51-835-8874
Phone Direct: +92-51-8466803
Mobile: +92-333-54097= 07
Skype ID: syed.fahar.abbas
Website: www.enterprisedb.com



--
Syed Fahar Abbas
Quality Management Group

<= /div>EnterpriseDB Corporation
Phone Office: +92-51-835-8874
Phone Dir= ect: +92-51-8466803
Mobile: +92-333-5409707
Skype ID: syed.= fahar.abbas
Website: www.enterprisedb.com



--
Syed Fahar= Abbas
Quality Management Group

EnterpriseDB Cor= poration
Phone Office: +92-51-835-8874
Phone Direct: +92-51-8466803
Mobile: +92-333-5409707
Skype ID: syed.fahar.abbas
Website:= www.enterprisedb= .com




--
Dave Page
Blog: http://pgsnake.blogspot.com<= /a>
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Ente= rprise PostgreSQL Company


--
Syed Fahar Abbas
=
Quality Management Group

EnterpriseDB CorporationPhone Office: +92-51-835-8874
Phone Direct: +92-51-8466803
Mobil= e: +92-333-5409707
Skype ID: syed.fahar.abbas
Website: www.enterprisedb.com=




--
Syed Fahar Abbas
Qual= ity Management Group

EnterpriseDB Corporation
Phone Office:= +92-51-835-8874
Phone Direct: +92-51-8466803
Mobile: +92-333-540= 9707
Skype ID: syed.fahar.abbas
Website: www.enterprisedb.com



--
Syed Fahar= Abbas
Quality Management Group

EnterpriseDB Cor= poration
Phone Office: +92-51-835-8874
Phone Direct: +92-51-8466803Mobile: +92-333-5409707
Skype ID: syed.fahar.abbas
Website: www.enterprisedb.com=
--001a11411b1cadff63053f46e7af--