Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bx5yk-0004ZJ-5U for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 05:33:22 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bx5yj-0007uz-Mk for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 05:33:21 +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 1bx5yh-0007us-UQ for pgadmin-hackers@postgresql.org; Thu, 20 Oct 2016 05:33:20 +0000 Received: from mail-lf0-x22c.google.com ([2a00:1450:4010:c07::22c]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bx5yd-0001Hc-9S for pgadmin-hackers@postgresql.org; Thu, 20 Oct 2016 05:33:18 +0000 Received: by mail-lf0-x22c.google.com with SMTP id b81so64971846lfe.1 for ; Wed, 19 Oct 2016 22:33:14 -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=V8EdXGO6uqHoo0vl5fSGS3Jc3/AJ4B4Mk/1sDPe6W1I=; b=0uTY1oKp5RZkyuKK1HSfchcrKOtNR1ZykhglQK9IdnhTue6ofNbZd6rhvOh+LdV9jE b6eGLvfe/CEZB04FJeKJ/pSfPtRi4PLjiaeJEsJdqHKZnv0uWe0lCqAZjH2obC9weR69 98sCQL+dIz8VUaXjBKN9QAOKfu8s763Lua+KKCzOYahI3eSc5oW9AhJptFilDrt2b0ZX aSddbcdXmsp1q8JI1orozwfDqxjXWQ5sG7yeSi2Mxj1kvgTgjnBpX682ilEPTafKGWXR JyQMMDUsqGb4RdOohPfpo/pLmIpmuW327hxY63lvY/jmtHc03fu4g4GnttnCKqaQub5m o7Mw== 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=V8EdXGO6uqHoo0vl5fSGS3Jc3/AJ4B4Mk/1sDPe6W1I=; b=CBdRYLhiMDvVd7wMGOzILYpvE4O1279dhp5lSyV/ZU08Ab6/5CYEymn0U9MKz5Afhi kPqLktks8rXUsFvyY0+GZ+y8cMF1mJNohjuUom9snzr2mznPwugI8p+yIo+8wL2vLIKH vuSUiLflsPPqVqNmIrhGBMAh7plwD4PvJhF1e/1rZgyiJ2ZqdmT7nhHukPruVq/dsmWC H4Ica3p3cCxGVOPxRyUy96pVSDnc8RIrEc8cBi1UrHOPGkgG+gTccVdIBiHYgqC4wAdm sJtcSAr0BbGyrpvwtXG6/phMgCMvXq5JZ9EocJ/0aRvqk07wy6XqoGu+gu0g0j4rNXWa uBYQ== X-Gm-Message-State: AA6/9RlbU4QPIV4lOUwAQScUSQP3nduouCtYVw0NRgNn4Ar+mMaIEeQCm3ZXmMB4EJIDYM3BKWk3SUMhqjMGJeZT X-Received: by 10.25.12.78 with SMTP id 75mr9987750lfm.177.1476941592435; Wed, 19 Oct 2016 22:33:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.92.219 with HTTP; Wed, 19 Oct 2016 22:33:11 -0700 (PDT) In-Reply-To: References: From: Fahar Abbas Date: Thu, 20 Oct 2016 10:33:11 +0500 Message-ID: Subject: Re: RM1849: Auto-generating security keys To: Dave Page Cc: Ashesh Vashi , pgadmin-hackers , Josh Berkus , =?UTF-8?B?RGV2cmltIEfDnE5Ew5xa?= , Magnus Hagander , Sandeep Thakkar , Hamid Quddus Akhtar Content-Type: multipart/alternative; boundary=001a113eb1fcf8b5d7053f45427c 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 --001a113eb1fcf8b5d7053f45427c Content-Type: text/plain; charset=UTF-8 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 --001a113eb1fcf8b5d7053f45427c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dave,

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
http= s://redmine.postgresql.org/issues/1849

On Wed, Oct 19, 2016 at 6:04 PM, Dave P= age <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 PostgreSQL Compa= ny

<= 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 <<= a href=3D"mailto:fahar.abbas@enterprisedb.com" target=3D"_blank">fahar.abba= s@enterprisedb.com> wrote:
=
Here is the output of if we copy config_local.py and = execute 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 d= atabase - '/home/fahar/.pgadmin/pgadmin4.db' does not exist.Entering initial setup mode...
NOTE: Configuring authentication for SE= RVER mode.


=C2=A0=C2=A0=C2=A0 Enter the email address and passwo= rd to use for the initial pgAdmin user=C2=A0=C2=A0=C2=A0=C2=A0 account:
=
Email address: fahar.abbas@enterprisedb.com
Password:
Retype passwo= rd:
Traceback (most recent call last):
=C2=A0 File "setup.py&quo= t;, 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 p= assword =3D encrypt_password(p1)
=C2=A0 File "/home/fahar/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(password).dec= ode('ascii')
=C2=A0 File "/home/fahar/venv/lib/python3= .5/site-packages/flask_security/utils.py", line 108, in get_= hmac
=C2=A0=C2=A0=C2=A0 'set to "%s"' % _security.pass= word_hash)
RuntimeError: The configuration value `SECURITY_PASSWORD_SALT= ` must not be None when the value of `SECURITY_PASSWORD_HASH` is set to &qu= ot;pbkdf2_sha512"
python setup.py
pgAdmin 4 - Application Initia= lisation
=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 co= nfiguration database - '/home/fahar/.pgadmin/pgadmin4.db' does= not exist.
Entering initial setup mode...
NOTE: Configuring authenti= cation for SERVER mode.


=C2=A0=C2=A0=C2=A0 Enter the email addre= ss 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:
Re= type password:
Traceback (most recent call last):
=C2=A0 File "s= etup.py", line 449, in <module>
=C2=A0=C2=A0=C2=A0 do_setup(a= pp)
=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"

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

Testing Enviro= nment
=C2=A0
Ubuntu 16.04 Linux 64:
------------------= --------------

pg-= AdminIV Development Environment Setup for Ubuntu=C2=A0 :<= /p>


1) Install GIT

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= font size=3D"2">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 re= quired for psycopg2 & pycrypto module

sudo apt-get install libpq-dev =

sudo apt-get install pyth= on3-dev

5) C= reate virtual environment

virtualenv -p python3 venv

6) Create mkdir Projects

7) Clone git repo in Projects

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

= 8) activate virtual environment

source venv/bin/activate

9) Install modules

pip3 install -r requirements_py3.tx= t

= 10) Edit the config.py file to config_local.py =C2=A0= resides in Projects\pgAdmin4\web=C2=A0=C2=A0

11)N= ow run setup.py fil= e =C2=A0(\Projects\pgAdmin4\web)

=C2=A0 =C2=A0 python setup.py

If user does not create config_lo= cal.py and do Python setup.py for new Development then SECURITY_PASSWORD_SA= LT message is also displayed:

Here is the output:
----= ---------------------

python setup.py
pgAdmin 4 - App= lication 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...
NOTE: Config= uring authentication for SERVER mode.


=C2=A0=C2=A0=C2=A0 Enter t= he 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
P= assword:
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_se= tup
=C2=A0=C2=A0=C2=A0 password =3D encrypt_password(p1)
=C2=A0 File = "/home/fahar/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(password).decode('ascii')
=C2=A0 File "/= home/fahar/venv/lib/python3.5/site-packages/flask_security/utils.= py", line 108, in get_hmac
=C2=A0=C2=A0=C2=A0 'set to "%s&= quot;' % _security.password_hash)
RuntimeError: The configuration va= lue `SECURITY_PASSWORD_SALT` must not be None when the value of `SECURITY_P= ASSWORD_HASH` is set to "pbkdf2_sha512"
(venv) fahar@fahar-vir= tual-machine:~/Projects/pgadmin4/web$


Is this expected?

On Wed= , Oct 19, 2016 at 1:37 PM, Fahar Abbas <fahar.abbas@enterprised= b.com> wrote:
Sure,

Will test this thoroughly after complete i= nvestigation.

Kind Regards,

On Wed, = Oct 19, 2016 at 1:27 PM, Dave Page <dpage@pgadmin.org> wrote= :
Patch applied.
Fahar, can you please test this thoroughly in desktop and serve= r modes, with both fresh and upgraded installations?

https://redmine.postgresql.org/issues/1849

Packagers: This change means that packages are no longer forced to creat= e a config_local.py file, and there is no longer any need to explicitly set= =C2=A0SECURITY_PASSWORD_SALT,=C2=A0= SECURITY_KEY and=C2=A0CSRF_SESSION_KE= Y 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, Ashe= sh Vashi <ashesh.vashi@enterprisedb.com> wr= ote:
= Hi Dave,

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


On Friday, October 14, 2016, Dav= e Page <dpage@pga= dmin.org> wrote:
Hi Dave,

On Tue, Oct 11, 2016 at 9:10 PM, Dave Pa= ge <dpage@pgadmin.org> wrote:
Hi Ashesh,

Can you please review the attached patch, and apply if you're happy wi= th 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 exist= ing pgAdmin 4 environment with 'web' mode.
- Apply the pa= tch
- Start the pgAdmin4 application (stand alone application).
- Open pgAdmin home page.
- Log out (if already login).<= /div>

And, you will see an exception.

I have figure out the issue with the patch.
We were settin= g the SECURITY_PASSWORD_SALT, after initializing the Security object.
=
Hence - it could not set the SECURITY_KEY, and SECURITY_PASSWORD_SALT = properly.

Hmm.
=C2=A0

I had moved the Security object initialization after fetching thes= e configurations from the database.
I have attached a addon patch= for the same.

OK, = thanks.
=C2=A0

Now - I run into another issue.
Because - th= e existing password was hashed using the old SECURITY_PASSWORD_SALT, I am n= o more able to login to pgAdmin 4.

I think - we ne= ed to think about different strategy for upgrading the configuration file i= n the 'web' mode.
I was thinking - we can store the exist= ing security configurations in the database during upgrade process in '= web' mode.

My c= oncern with that is that we'll likely be storing the default config val= ues in many cases, thus for those users, perpetuating the problem.

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

OK, so I've been thinking about this and experimenting f= or a couple of hours, as well as annoying the crap out of Magnus by thinkin= g out loud in his general direction, and it looks like this isn't a maj= or problem as from what I can see, =C2=A0SECURITY_PASSWORD_SALT is (aside f= rom 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 pas= slib which salts and hashes it. I did some testing, and found that two user= s with the same password end up with different hashes in the database, so c= learly 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 ac= ross different installations/databases.

So, I beli= eve we can do as you suggest and migrate existing values for SECURITY_PASSW= ORD_SALT, given that there's clearly some other per user and per instal= lation/database salting going on anyway. New installations can have the ran= dom value for SECURITY_PASSWORD_SALT.
We= do not need to generate the random SECURITY_PASSWORD_SALT during upgrade m= ode, which was wrong added in my addon patch.

Plea= se find the updated patch.

Otherwise - looks good = to me.
Please commit the new patch (if you're ok with the cha= nge).


--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA:=C2=A0Enterprise PostgreSQL Company<= /p>



I don't believe= SECURITY_KEY and=C2=A0CSRF_SESSION_KEY are issues either, as they're u= sed for purposes that are essentially ephemeral, and thus can be changed du= ring an upgrade.

Adding Magnus as I'd apprecia= te any thoughts he may have.

Patch attached - plea= se review (Ashesh, but others too would be appreciated)!

Thanks.


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

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





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

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



--
Syed Fahar Abbas
Quality Management Group

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



--
Syed Fahar Abbas
Quality Management Group

Enter= priseDB Corporation
Phone Office: +92-51-835-8874
Phone Direct: +92-51= -8466803
Mobile: +92-333-5409707
Skype ID: syed.fahar.abbas<= br>Website: www.e= nterprisedb.com



--
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=




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

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



--
Syed Fahar Abbas
Quality Management Group

E= nterpriseDB Corporation
Phone Office: +92-51-835-8874
Phone Direct: += 92-51-8466803
Mobile: +92-333-5409707
Skype ID: syed.fahar.abbas
W= ebsite: www.enter= prisedb.com
--001a113eb1fcf8b5d7053f45427c--