Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bx79f-0004vE-Tf for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 06:48:44 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bx79f-0001Gl-G3 for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 06:48:43 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bx76M-0000xr-24 for pgadmin-hackers@postgresql.org; Thu, 20 Oct 2016 06:45:18 +0000 Received: from mail-lf0-x234.google.com ([2a00:1450:4010:c07::234]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bx76D-0002dh-5z for pgadmin-hackers@postgresql.org; Thu, 20 Oct 2016 06:45:16 +0000 Received: by mail-lf0-x234.google.com with SMTP id l131so64521007lfl.2 for ; Wed, 19 Oct 2016 23:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vPh2FiMp+FN59q2VnKlFFvW79FKBHIM7NtqCqKnxaKI=; b=0m/S3UUFlMiXbrqgAfrK+vuNHPXj3FE3xsI+b0WvoGGiDwbVnONrPE1WGpr4m+BA+H JB/szxHDnnNGjwZiXZOVhXhWumwFeOO/oolgRW59XEAGhKIPi1VGMUVZU2PrR264W30p Yoy9RSRhgZ4CzsIc2uk7isky7kA0Kc9mTknljotnn7J21ZBeymFbH2d7zvgNBJ3Ajd3Z ZEPHpjD9aevHyN7UyIYf5t2WOfIq486L9vbz19Rr6Cvpu7oZlIKPhIaeU/2nQrBhKeLu 3Kw3irDyMq4+YEfgIJs5ku/dU16fe5mcfJVpZZv1rUO9+EpZ5/fhzYF+jVMyFxX5p6eH /IBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vPh2FiMp+FN59q2VnKlFFvW79FKBHIM7NtqCqKnxaKI=; b=APQRb87jHuojpyityLk0j7VHYpN+BuVtv+18vGc1MyAeCDVb9oTtXnSttfJSzb5Dnm okG9dSpOkTkAHw/jlXycYO1WYM/xzk3+5wrYz0oNzdahVfr41MIdbk+IKmpcjE9HdtCN Njq6Miz5Tnu203jRoazUMBU0tlhBLbEIqamSdqabYoA8Sj3Qzn/eVoID3jgcgZ0P+fwa Qc6eGhcGH6HvreOPp7HD+7/V7EIzYkMW/ts1cBSnazYX/prXR9xLtHyYB3hp7jiYlQO5 SRgC3uPO845d+ylWrCxWil/Je4TTWMgKRN7UV/ilGT0RS/Rf2FIcFdMGIPazQdc6FxH8 vpBQ== X-Gm-Message-State: AA6/9RkrNI+56bH2v/EPTbN3HQ0XroPga0fTRSfW522ayIFYccnsGF7y3VfjD9UX0hIadw== X-Received: by 10.28.55.203 with SMTP id e194mr4924465wma.97.1476945904648; Wed, 19 Oct 2016 23:45:04 -0700 (PDT) Received: from ?IPv6:2a02:c7f:6c13:9a00:683a:8c53:b68f:c36c? ([2a02:c7f:6c13:9a00:683a:8c53:b68f:c36c]) by smtp.gmail.com with ESMTPSA id w1sm25395025wje.36.2016.10.19.23.45.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 19 Oct 2016 23:45:03 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-665650AF-107E-4434-9D82-8E7FDE11C58E Mime-Version: 1.0 (1.0) Subject: Re: RM1849: Auto-generating security keys From: Dave Page X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Thu, 20 Oct 2016 07:45:02 +0100 Cc: Fahar Abbas , Ashesh Vashi , pgadmin-hackers , Josh Berkus , =?utf-8?Q?Devrim_G=C3=9CND=C3=9CZ?= , Magnus Hagander , Sandeep Thakkar , Hamid Quddus Akhtar Content-Transfer-Encoding: 7bit Message-Id: References: To: Murtuza Zabuawala 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 --Apple-Mail-665650AF-107E-4434-9D82-8E7FDE11C58E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I think you'll also need to set the version back to 13 in the version table.= --=20 Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK:http://www.enterprisedb.com The Enterprise PostgreSQL Company > On 20 Oct 2016, at 07:00, Murtuza Zabuawala wrote: >=20 > Could you delete 'keys' table from pgadmin4.db file & try again?=20 >=20 > -- > Regards, > Murtuza Zabuawala > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >=20 >> On Thu, Oct 20, 2016 at 11:26 AM, Fahar Abbas wrote: >> Murtaza, >>=20 >> I have applied this patch and there is no success on new pgAdmin4 setup a= s well as existing pgAdmin4 setup. >>=20 >>> On Thu, Oct 20, 2016 at 10:45 AM, Murtuza Zabuawala wrote: >>> Hi, >>>=20 >>> PFA patch to fix the issue for Pyhton3. >>> RM#1849 >>>=20 >>> -- >>> Regards, >>> Murtuza Zabuawala >>> EnterpriseDB: http://www.enterprisedb.com >>> The Enterprise PostgreSQL Company >>>=20 >>>> On Thu, Oct 20, 2016 at 11:03 AM, Fahar Abbas wrote: >>>> Hi Dave, >>>>=20 >>>> I have reopened following 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.org/issues/1849=20 >>>>=20 >>>>> On Wed, Oct 19, 2016 at 6:04 PM, Dave Page wrote: >>>>> Patch applied. >>>>>=20 >>>>>> On Wed, Oct 19, 2016 at 11:55 AM, Ashesh Vashi wrote: >>>>>> Hi Fahar, >>>>>>=20 >>>>>> Please log the case on redmine. >>>>>> Please find the attached patch, please apply it locally, and test it.= >>>>>>=20 >>>>>> And, please update the case, and this mail chain accordingly. >>>>>>=20 >>>>>> -- >>>>>> Thanks & Regards, >>>>>>=20 >>>>>> Ashesh Vashi >>>>>> EnterpriseDB INDIA: Enterprise PostgreSQL Company >>>>>>=20 >>>>>> http://www.linkedin.com/in/asheshvashi >>>>>>=20 >>>>>>> On Wed, Oct 19, 2016 at 3:47 PM, Fahar Abbas wrote: >>>>>>> Here is the output of if we copy config_local.py and execute python s= etup.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 >>>>>>>=20 >>>>>>>=20 >>>>>>> The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' does= not exist. >>>>>>> Entering initial setup mode... >>>>>>> NOTE: Configuring authentication for SERVER mode. >>>>>>>=20 >>>>>>>=20 >>>>>>> Enter the email address and password to use for the initial pgAd= min user account: >>>>>>>=20 >>>>>>> Email address: fahar.abbas@enterprisedb.com >>>>>>> Password:=20 >>>>>>> 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 =3D encrypt_password(p1) >>>>>>> File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/= utils.py", line 150, in encrypt_password >>>>>>> signed =3D 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 n= ot be None when the value of `SECURITY_PASSWORD_HASH` is set to "pbkdf2_sha5= 12" >>>>>>> python setup.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 >>>>>>>=20 >>>>>>> User can not do any setup for web based now. >>>>>>>=20 >>>>>>>=20 >>>>>>> The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' does= not exist. >>>>>>> Entering initial setup mode... >>>>>>> NOTE: Configuring authentication for SERVER mode. >>>>>>>=20 >>>>>>>=20 >>>>>>> Enter the email address and password to use for the initial pgAd= min user account: >>>>>>>=20 >>>>>>> Email address: fahar.abbas@enterprisedb.com >>>>>>> Password:=20 >>>>>>> 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 =3D encrypt_password(p1) >>>>>>> File "/home/fahar/venv/lib/python3.5/site-packages/flask_security/= utils.py", line 150, in encrypt_password >>>>>>> signed =3D 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 n= ot be None when the value of `SECURITY_PASSWORD_HASH` is set to "pbkdf2_sha5= 12" >>>>>>>=20 >>>>>>>> On Wed, Oct 19, 2016 at 3:03 PM, Fahar Abbas wrote: >>>>>>>> Dave, >>>>>>>>=20 >>>>>>>> Testing Environment >>>>>>>> =20 >>>>>>>> Ubuntu 16.04 Linux 64: >>>>>>>> -------------------------------- >>>>>>>> pg-AdminIV Development Environment Setup for Ubuntu : >>>>>>>>=20 >>>>>>>> 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 & pycryp= to 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 =20 >>>>>>>> 11)Now run setup.py file (\Projects\pgAdmin4\web) >>>>>>>> python setup.py >>>>>>>>=20 >>>>>>>> If user does not create config_local.py and do Python setup.py for n= ew Development then SECURITY_PASSWORD_SALT message is also displayed: >>>>>>>>=20 >>>>>>>> Here is the output: >>>>>>>> ------------------------- >>>>>>>>=20 >>>>>>>> python setup.py=20 >>>>>>>> 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 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The configuration database - '/home/fahar/.pgadmin/pgadmin4.db' doe= s not exist. >>>>>>>> Entering initial setup mode... >>>>>>>> NOTE: Configuring authentication for SERVER mode. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Enter the email address and password to use for the initial pgA= dmin user account: >>>>>>>>=20 >>>>>>>> Email address: fahar.abbas@enterprisedb.com >>>>>>>> Password:=20 >>>>>>>> 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 =3D encrypt_password(p1) >>>>>>>> File "/home/fahar/venv/lib/python3.5/site-packages/flask_security= /utils.py", line 150, in encrypt_password >>>>>>>> signed =3D 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_sh= a512" >>>>>>>> (venv) fahar@fahar-virtual-machine:~/Projects/pgadmin4/web$=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Is this expected? >>>>>>>>=20 >>>>>>>>> On Wed, Oct 19, 2016 at 1:37 PM, Fahar Abbas wrote: >>>>>>>>> Sure, >>>>>>>>>=20 >>>>>>>>> Will test this thoroughly after complete investigation. >>>>>>>>>=20 >>>>>>>>> Kind Regards, >>>>>>>>>=20 >>>>>>>>>> On Wed, Oct 19, 2016 at 1:27 PM, Dave Page wr= ote: >>>>>>>>>> Patch applied. >>>>>>>>>>=20 >>>>>>>>>> Fahar, can you please test this thoroughly in desktop and server m= odes, with both fresh and upgraded installations? >>>>>>>>>>=20 >>>>>>>>>> https://redmine.postgresql.org/issues/1849 >>>>>>>>>>=20 >>>>>>>>>> Packagers: This change means that packages are no longer forced t= o create a config_local.py file, and there is no longer any need to explicit= ly set SECURITY_PASSWORD_SALT, SECURITY_KEY and CSRF_SESSION_KEY in the conf= ig (in fact, they should be removed for new installations, if you have inclu= ded them in 1.0) >>>>>>>>>>=20 >>>>>>>>>> Thanks. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On Wed, Oct 19, 2016 at 6:46 AM, Ashesh Vashi wrote: >>>>>>>>>>> Hi Dave, >>>>>>>>>>>=20 >>>>>>>>>>>> On Sat, Oct 15, 2016 at 8:02 AM, Dave Page w= rote: >>>>>>>>>>>> Hi >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> On Friday, October 14, 2016, Dave Page wro= te: >>>>>>>>>>>>> Hi >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Thursday, October 13, 2016, Ashesh Vashi wrote: >>>>>>>>>>>>>> Hi Dave, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Tue, Oct 11, 2016 at 9:10 PM, Dave Page wrote: >>>>>>>>>>>>>>> Hi Ashesh, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Can you please review the attached patch, and apply if you'r= e happy with it? >>>>>>>>>>>>>> Overall the patch looked good to me. >>>>>>>>>>>>>> But - I encounter an issue in 'web' mode, which wont happen w= ith 'runtime'. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 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). >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> And, you will see an exception. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I have figure out the issue with the patch. >>>>>>>>>>>>>> We were setting the SECURITY_PASSWORD_SALT, after initializin= g the Security object. >>>>>>>>>>>>>> Hence - it could not set the SECURITY_KEY, and SECURITY_PASSW= ORD_SALT properly. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hmm. >>>>>>>>>>>>> =20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I had moved the Security object initialization after fetching= these configurations from the database. >>>>>>>>>>>>>> I have attached a addon patch for the same. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> OK, thanks. >>>>>>>>>>>>> =20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Now - I run into another issue. >>>>>>>>>>>>>> Because - the existing password was hashed using the old SECU= RITY_PASSWORD_SALT, I am no more able to login to pgAdmin 4. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I think - we need to think about different strategy for upgra= ding the configuration file in the 'web' mode. >>>>>>>>>>>>>> I was thinking - we can store the existing security configura= tions in the database during upgrade process in 'web' mode. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> My concern with that is that we'll likely be storing the defau= lt config values in many cases, thus for those users, perpetuating the probl= em. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I guess what we need to do is re-encrypt the password during t= he 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. S= igh... Needs more thought.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> OK, so I've been thinking about this and experimenting for a co= uple of hours, as well as annoying the crap out of Magnus by thinking out lo= ud 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 k= ey not a salt) not the only salting that's done.=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> It looks like it's used system-wide as the key to generate an H= MAC of the users password, which is then passed to passlib which salts and h= ashes it. I did some testing, and found that two users with the same passwor= d 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 s= omething else ensuring the hashes are unique across different installations/= databases. >>>>>>>>>>>>=20 >>>>>>>>>>>> So, I believe we can do as you suggest and migrate existing val= ues for SECURITY_PASSWORD_SALT, given that there's clearly some other per us= er and per installation/database salting going on anyway. New installations c= an have the random value for SECURITY_PASSWORD_SALT. >>>>>>>>>>>=20 >>>>>>>>>>> We do not need to generate the random SECURITY_PASSWORD_SALT dur= ing upgrade mode, which was wrong added in my addon patch. >>>>>>>>>>>=20 >>>>>>>>>>> Please find the updated patch. >>>>>>>>>>>=20 >>>>>>>>>>> Otherwise - looks good to me. >>>>>>>>>>> Please commit the new patch (if you're ok with the change). >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Thanks & Regards, >>>>>>>>>>>=20 >>>>>>>>>>> Ashesh Vashi >>>>>>>>>>> EnterpriseDB INDIA: Enterprise PostgreSQL Company >>>>>>>>>>>=20 >>>>>>>>>>> http://www.linkedin.com/in/asheshvashi =20 >>>>>>>>>>>>=20 >>>>>>>>>>>> I don't believe SECURITY_KEY and CSRF_SESSION_KEY are issues ei= ther, as they're used for purposes that are essentially ephemeral, and thus c= an be changed during an upgrade. >>>>>>>>>>>>=20 >>>>>>>>>>>> Adding Magnus as I'd appreciate any thoughts he may have. >>>>>>>>>>>>=20 >>>>>>>>>>>> Patch attached - please review (Ashesh, but others too would be= appreciated)! >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> --=20 >>>>>>>>>>>> Dave Page >>>>>>>>>>>> Blog: http://pgsnake.blogspot.com >>>>>>>>>>>> Twitter: @pgsnake >>>>>>>>>>>>=20 >>>>>>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com >>>>>>>>>>>> The Enterprise PostgreSQL Company >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> --=20 >>>>>>>>>> Dave Page >>>>>>>>>> Blog: http://pgsnake.blogspot.com >>>>>>>>>> Twitter: @pgsnake >>>>>>>>>>=20 >>>>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com >>>>>>>>>> The Enterprise PostgreSQL Company >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> --=20 >>>>>>>>> Syed Fahar Abbas >>>>>>>>> Quality Management Group >>>>>>>>>=20 >>>>>>>>> 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 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> --=20 >>>>>>>> Syed Fahar Abbas >>>>>>>> Quality Management Group >>>>>>>>=20 >>>>>>>> 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 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> --=20 >>>>>>> Syed Fahar Abbas >>>>>>> Quality Management Group >>>>>>>=20 >>>>>>> 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 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Dave Page >>>>> Blog: http://pgsnake.blogspot.com >>>>> Twitter: @pgsnake >>>>>=20 >>>>> EnterpriseDB UK: http://www.enterprisedb.com >>>>> The Enterprise PostgreSQL Company >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Syed Fahar Abbas >>>> Quality Management Group >>>>=20 >>>> 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 >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Syed Fahar Abbas >> Quality Management Group >>=20 >> 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 >=20 --Apple-Mail-665650AF-107E-4434-9D82-8E7FDE11C58E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I think you'll also need to set the ve= rsion back to 13 in the version table.

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

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

On 20 Oct= 2016, at 07:00, Murtuza Zabuawala <murtuza.zabuawala@enterprisedb.com> wrote:

Could you delete 'keys' t= able from pgadmin4.db file & try again? 

--
Regard= s,
Murtuza Zabuawala
<= span style=3D"color:rgb(136,136,136)">EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQ= L Company


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

I have appl= ied this patch and there is no success on new pgAdmin4 setup as well as exis= ting pgAdmin4 setup.

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

PFA patch t= o fix the issue for Pyhton3.
RM#1849

--
Regards,
Murtuza Zabuawal= a
EnterpriseDB: http://ww= w.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 follow= ing 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.org/issu= es/1849

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

On Wed, Oct 19, 2016 at 11:55 AM, Ashesh Vashi <ashesh.vashi@e= nterprisedb.com> wrote:
=
Hi Fahar,

Please log the case on r= edmine.
Please find the attached patch, please apply it locally, and tes= t it.

And, please update the case, and this mail ch= ain 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.c= om> wrote:
<= div>Here is the output of if we copy config_local.py and execute python setu= p.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 setup mode...<= br>NOTE: Configuring authentication for SERVER mode.


  =   Enter the email address and password to use for the initial pgAdmin u= ser     account:

Email address: fahar.abbas@enterprisedb.co= m
Password:
Retype password:
Traceback (most recent call last)= :
  File "setup.py", line 449, in <module>
  &nbs= p; do_setup(app)
  File "setup.py", line 96, in do_setup
 &n= bsp;  password =3D encrypt_password(p1)
  File "/home/fahar/ven= v/lib/python3.5/site-packages/flask_security/utils.py", line 150, i= n encrypt_password
    signed =3D get_hmac(password).decod= e('ascii')
  File "/home/fahar/venv/lib/python3.5/site-pac= kages/flask_security/utils.py", line 108, in get_hmac
  &n= bsp; 'set to "%s"' % _security.password_hash)
RuntimeError: The configura= tion value `SECURITY_PASSWORD_SALT` must not be None when the value of `SECU= RITY_PASSWORD_HASH` is set to "pbkdf2_sha512"
python setup.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
User can not do any setup for web based now.


The configuration database - '/home/fahar/.pgadmin/pgadmin4.d= b' does not exist.
Entering initial setup mode...
NOTE: Configuring au= thentication for SERVER mode.


    Enter the email a= ddress and password to use for the initial pgAdmin user   &nb= sp; account:

Email address: fahar.abbas@enterprisedb.com
Password:
R= etype password:
Traceback (most recent call last):
  File "setup.= py", line 449, in <module>
    do_setup(app)
&nbs= p; File "setup.py", line 96, in do_setup
    password =3D e= ncrypt_password(p1)
  File "/home/fahar/venv/lib/python3.5/site= -packages/flask_security/utils.py", line 150, in encrypt_password
&n= bsp;   signed =3D 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"' % _se= curity.password_hash)
RuntimeError: The configuration value `SECURITY_PAS= SWORD_SALT` must not be None when the value of `SECURITY_PASSWORD_HASH` is s= et to "pbkdf2_sha512"

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

Testing Environment
 
Ubuntu 16.04 Linu= x 64:
--------------------------------

pg-AdminIV Development Environment S= etup for Ubuntu  :


<= span style=3D"font-family:arial;color:rgb(0,0,0);background-color:transparen= t;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none= ;vertical-align:baseline">1) Install GIT

sudo apt-get install git

2) Install pip3

sudo apt-get install python3-pip

3) Install virtualenv

sudo pip3 install v= irtualenv

4) ins= tall below dependency as it is required for psycopg2 & pycrypto module

sudo apt-get inst= all libpq-dev

s= udo apt-get install python3-dev

5) Create virtual environment

virtualenv -p python3 venv

6) Create mkdir Projects

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">7) Clone git repo in Projects
<= /span>

git clone http://git.= postgresql.org/git/pgadmin4.git=

8) activate virtual en= vironment

source= venv/bin/activate

9) Install modules

pip3 install -r requirements_py3.txt

10) Edit the conf= ig.py file to config_local.py  resides in Projects\pgAdmin4\web  

11)Now run setup.py f= ile  (\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:<= br>
Here is the output:
-------------------------
=

python setup.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.

    Enter the email address and password to use for the init= ial pgAdmin user     account:

Email address: fahar.abbas@en= terprisedb.com
Password:
Retype password:
Traceback (most rece= nt call last):
  File "setup.py", line 449, in <module>
&nb= sp;   do_setup(app)
  File "setup.py", line 96, in do_setu= p
    password =3D encrypt_password(p1)
  File "/h= ome/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py= ", line 150, in encrypt_password
    signed =3D get_hmac(p= assword).decode('ascii')
  File "/home/fahar/venv/lib/python3.<= wbr>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 v= alue of `SECURITY_PASSWORD_HASH` is set to "pbkdf2_sha512"
(venv) fahar@f= ahar-virtual-machine:~/Projects/pgadmin4/web$


Is this expected?

=
On Wed, Oct 19, 2= 016 at 1:37 PM, Fahar Abbas <fahar.abbas@enterprisedb.com>= wrote:
S= ure,

Will test this thoroughly after complete investigation.
Kind Regards,

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

Fahar, can you please te= st this thoroughly in desktop and server modes, with both fresh and upgraded= installations?


Packagers: This change means that pac= kages are no longer forced to create a config_local.py file, and there is no= longer any need to explicitly set SEC= URITY_PASSWORD_SALT, SECUR= ITY_KEY and CSRF_SESSION_KEY in the config (in fact, they should be rem= oved 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 <dpage@pgadmin.org>= wrote:
Hi


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

On Thursday, October 1= 3, 2016, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrot= e:
Hi D= ave,

On T= ue, Oct 11, 2016 at 9:10 PM, Dave Page <dpage@pgadmi= n.org> wrote:
Hi Ashesh,

Can you please review the attached patch, a= nd apply if you're happy with it?
Overall the patch l= ooked good to me.
But - I encounter an issue in 'web' mode, which w= ont happen with 'runtime'.

Steps for reproduction o= n existing pgAdmin 4 environment with 'web' mode.
- Apply the patc= h
- 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 S= ECURITY_PASSWORD_SALT, after initializing the Security object.
Hen= ce - it could not set the SECURITY_KEY, and SECURITY_PASSWORD_SALT properly.=

Hmm.
&nbs= p;

I ha= d moved the Security object initialization after fetching these configuratio= ns from the database.
I have attached a addon patch for the same.<= /div>

OK, thanks.
 

Now - I run into another issue.
Because - the existing password w= as hashed using the old SECURITY_PASSWORD_SALT, I am no more able to login t= o pgAdmin 4.

I think - we need to think about diffe= rent strategy for upgrading the configuration file in the 'web' mode.
<= div>I was thinking - we can store the existing security configurations in th= e database during upgrade process in 'web' mode.

My concern with that is that we'll likely be st= oring the default config values in many cases, thus for those users, perpetu= ating the problem.

I guess what we need to do is re= -encrypt the password during the upgrade - however, that makes me think; we t= hen 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 an= d experimenting for a couple of hours, as well as annoying the crap out of M= agnus by thinking out loud in his general direction, and it looks like this i= sn'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 k= ey to generate an HMAC of the users password, which is then passed to passli= b which salts and hashes it. I did some testing, and found that two users wi= th the same password end up with different hashes in the database, so clearl= y there is also per-user salting happening. I also created two users, then d= ropped the database and created the same user accounts with the same passwor= ds again, and found that the resulting hashes were different in both databas= es - thus there is something else ensuring the hashes are unique across diff= erent installations/databases.

So, I believe we can= do as you suggest and migrate existing values for SECURITY_PASSWORD_SALT, g= iven that there's clearly some other per user and per installation/database s= alting going on anyway. New installations can have the random value for SECU= RITY_PASSWORD_SALT.
We do not need to gen= erate the random SECURITY_PASSWORD_SALT during upgrade mode, which was wrong= added in my addon patch.

Please find the updated p= atch.

Otherwise - looks good to me.
Pleas= e commit the new patch (if you're ok with the change).


--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: 
Enterprise PostgreSQL Company



I don't believe SECURITY_KEY and&n= bsp;CSRF_SESSION_KEY are issues either, as they're used for purposes that ar= e 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 t= oo would be appreciated)!

Thanks.


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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgr= eSQL Company





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

EnterpriseDB UK: http://www.enterprisedb.comThe Enterprise PostgreSQL Company



--
Syed Fahar Ab= bas
Quality Management Group

EnterpriseDB Corporati= on
Phone Office: +92-51-835-8874
Phone Direct: +92-51-8466803
Mob= ile: +92-333-5409707
Skype ID: syed.fahar.abbas
Website: www.enterprisedb.com
=



--
Syed Fahar Abba= s
Quality Management Group

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



--
Syed Fahar Abbas
Quali= ty Management Group

EnterpriseDB Corporation
Phone Office: +92-5= 1-835-8874
Phone Direct: +92-51-8466803
Mobile: +92-333-5409707<= br>Skype ID: syed.fahar.abbas
Website: www.enterprisedb.com




--
<= div class=3D"m_313149211259488251m_7722923972352742530m_-5631392044300219617= m_2500240099394767488gmail_signature" data-smartmail=3D"gmail_signature">Dav= e Page
Blog: ht= tp://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: <= a href=3D"http://www.enterprisedb.com" target=3D"_blank">http://www.enterpri= sedb.com
The Enterprise PostgreSQL Company



--
Syed Fahar Abbas=
Quality Management Group

EnterpriseDB Corporation<= br>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 Fa= har 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
=

= --Apple-Mail-665650AF-107E-4434-9D82-8E7FDE11C58E--