Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwoej-0003fL-66 for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Oct 2016 11:03:33 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bwoei-0004Zn-Ho for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Oct 2016 11:03:32 +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 1bwoeU-0004LY-Aj for pgadmin-hackers@postgresql.org; Wed, 19 Oct 2016 11:03:18 +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 1bwoeP-0000Yf-Mt for pgadmin-hackers@postgresql.org; Wed, 19 Oct 2016 11:03:17 +0000 Received: by mail-lf0-x234.google.com with SMTP id l131so18232439lfl.2 for ; Wed, 19 Oct 2016 04:03:13 -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=1jfs4uyftwziuQO9ovn0aLhv+JRJMK7O4lKbnxLVhaY=; b=SXADa/TeSNGZxqRHoocmcGKKjHlOUtki1NvruVDYnXsE/DUDNfQbp0tNhvzL966R1g mVQiPjmdsHFZiCTn9S4OrHrynBeHb5G1BV9eHPMS36ZS6tBCO/OScAiKw7o9YOxLHU1M z8QyNqPWdqynVZE3dEygg5Zxk3Wyvk75VDjrVv1vfXjqkb4hbDnJwot6xmej6gQmvxW2 4d3akbxxnszxxxRZQVMIGISmxlr/1QpZKFb61VGi9pc8LMDLvF9B+bah0i44qgThyySK NZqa2J1YmQpZafoky+2dUWOmYE9XiT90MCKz0LpSJRIEx1kk0ce0PI9zLc1Njmm9hsst CBjA== 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=1jfs4uyftwziuQO9ovn0aLhv+JRJMK7O4lKbnxLVhaY=; b=c7PNg4V3TkTAhjG9wDwgHP6PplYd+HtnPKAeH7fPLW+IZTgOnYkRuQD7CXttcyXjpv 0gTgT8XYzfzDUV1ceeKXb+B+oNGRc9M6x93sBpLYE1PX7Z0DylmuVIjf3NoU3u254JFO JNs0O/8eLIsi04fKuXDuQ/7Hgik/08uxzryifL+IOKU4CGJ21VayeDIiZwXbqqnd6eKC 2oxxeMkKz8k5Xt+Jt7c7IGfh5xTu5YkSzElc6ODDAqAqa5xktDQCI50FwmrE1Isf05zE QvF6/vAzkyNwGikJaChYmA70Gl1Qo7KyClPVMvyH0ZiRqENrPnkzWBl6VLv5KLOvHCXi 5xTQ== X-Gm-Message-State: AA6/9RnDlDzM1glyqH6xVdsUVpHuD5gP/GzdKnb5ifOlWpekvpvXurDafO3RGkgkL0Vs3vk6uKDwuotpSDA5vrcM X-Received: by 10.25.16.208 with SMTP id 77mr3777519lfq.167.1476874990183; Wed, 19 Oct 2016 04:03:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.92.219 with HTTP; Wed, 19 Oct 2016 04:03:09 -0700 (PDT) In-Reply-To: References: From: Fahar Abbas Date: Wed, 19 Oct 2016 16:03:09 +0500 Message-ID: Subject: Re: RM1849: Auto-generating security keys To: Ashesh Vashi Cc: Dave Page , pgadmin-hackers , Josh Berkus , =?UTF-8?B?RGV2cmltIEfDnE5Ew5xa?= , Magnus Hagander , Sandeep Thakkar , Hamid Quddus Akhtar Content-Type: multipart/alternative; boundary=001a114032942afa40053f35c1e2 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 --001a114032942afa40053f35c1e2 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 19, 2016 at 3:55 PM, Ashesh Vashi wrote: > Hi Fahar, > > Please log the case on redmine. > https://redmine.postgresql.org/issues/1871 > Please find the attached patch, please apply it locally, and test it. > > And, please update the case, and this mail chain accordingly. > > Sure Will test the patch and update the status 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 > 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 >> > > -- 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 --001a114032942afa40053f35c1e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Oct 19, 2016 at 3:55 PM, Ashesh Vashi <ashesh.vash= i@enterprisedb.com> wrote:
Hi Fahar,

Plea= se log the case on redmine.

--

Thanks &= amp; Regards,

Ashesh Vashi
EnterpriseDB IN= DIA: Enter= prise PostgreSQL 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_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 configura= tion database - '/home/fahar/.pgadmin/pgadmin4.db' does not ex= ist.
Entering initial setup mode...
NOTE: Configuring 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 accoun= t:

Email address: fahar.abbas@enterprisedb.com
Password:
Retype pa= ssword:
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 "/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/py= thon3.5/site-packages/flask_security/utils.py", line 108, in= get_hmac
=C2=A0=C2=A0=C2=A0 '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 t= o "pbkdf2_sha512"
python setup.py
pgAdmin 4 - Application I= nitialisation
=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: Configuring au= thentication 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
Password: =
Retype password:
Traceback (most recent call last):
=C2=A0 File &= quot;setup.py", line 449, in <module>
=C2=A0=C2=A0=C2=A0 do_s= etup(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 "/hom= e/fahar/venv/lib/python3.5/site-packages/flask_security/utils.py&= quot;, line 150, in encrypt_password
=C2=A0=C2=A0=C2=A0 signed =3D get_h= mac(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"'= % _security.password_hash)
RuntimeError: The configuration value `SECUR= ITY_PASSWORD_SALT` must not be None when the value of `SECURITY_PASSWORD_HA= SH` is set to "pbkdf2_sha512"

On Wed, O= ct 19, 2016 at 3:03 PM, Fahar Abbas <fahar.abbas@enterprisedb.c= om> wrote:
Dave,

Testing Environment
=C2=A0
Ubuntu 16.04 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 virtualenv=

sudo pip3 install = virtualenv

4= ) install below dependency as it is required for psycopg2 & pycrypto mo= dule

sudo ap= t-get install libpq-dev

sudo apt-get install python3-dev

5) Create virtual environment

virtualenv -p python3= venv

6) Create mkdir Pr= ojects

7= ) Clone git repo in Projects

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

8) activate virtual environment

source venv/bin/activate<= /font>

9) Install modules<= /span>

pip3 install= -r requirements_py3.txt

10) Edit the config.py file to= config_local.py =C2=A0resides in Projects\pgAdm= in4\web=C2=A0=C2=A0

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

=C2=A0 =C2=A0 python setup.py
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:
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 databas= e - '/home/fahar/.pgadmin/pgadmin4.db' does not exist.
Ente= ring initial setup mode...
NOTE: Configuring authentication for SERVER m= ode.


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

Em= ail address: fahar.abbas@enterprisedb.com
Password:
Retype password:
T= raceback (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 "/home/fahar/venv/lib/python3.= 5/site-packages/flask_security/utils.py", line 150, in encry= pt_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"' % _security.password_has= h)
RuntimeError: The configuration value `SECURITY_PASSWORD_SALT` must n= ot be None when the value of `SECURITY_PASSWORD_HASH` is set to "pbkdf= 2_sha512"
(venv) fahar@fahar-virtual-machine:~/Projects/pgadmi= n4/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.

Ki= nd Regards,

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

Fahar, can yo= u please test this thoroughly in desktop and server modes, with both fresh = and upgraded installations?


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=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@en= terprisedb.com> wrote:
Hi Dave,

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


On Friday, October 14, 20= 16, Dave Page <dp= age@pgadmin.org> wrote:
Hi

On Thursday, October 13, 2016, Ashesh Vashi <ash= esh.vashi@enterprisedb.com> wrote:
Hi Dave,

On Tue, Oct 11, 2016 at 9:10 PM= , Dave Page <dpage@pgadmin.org> wrote= :
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 hap= pen with 'runtime'.

Steps for reproduction= on existing pgAdmin 4 environment with 'web' mode.
- App= ly the patch
- Start the pgAdmin4 application (stand alone applic= ation).
- 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 we= re setting the SECURITY_PASSWORD_SALT, after initializing the Security obje= ct.
Hence - it could not set the SECURITY_KEY, and SECURITY_PASSW= ORD_SALT properly.

= Hmm.
=C2=A0

I had moved the Security object initialization after fetc= hing these configurations from the database.
I have attached a ad= don patch for the same.

=
OK, thanks.
=C2=A0

Now - I run into another issue.
Bec= ause - the existing password was hashed using the old SECURITY_PASSWORD_SAL= T, I am no more able to login to pgAdmin 4.

I thin= k - we need to think about different strategy for upgrading the configurati= on 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 c= onfig values in many cases, thus for those users, perpetuating the problem.=

I guess what we need to do is re-encrypt the pass= word during the upgrade - however, that makes me think; we then have both t= he key and the encrypted passwords in the same database which is clearly no= t a good idea. Sigh... Needs more thought.=C2=A0
OK, so I've been thinking about this and experi= menting for a couple of hours, as well as annoying the crap out of Magnus b= y thinking out loud in his general direction, and it looks like this isn= 9;t a major problem as from what I can see, =C2=A0SECURITY_PASSWORD_SALT is= (aside from really being a key not a salt) not the only salting that's= done.=C2=A0

It looks like it's used system-wi= de as the key to generate an HMAC of the users password, which is then pass= ed 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 datab= ase, so clearly there is also per-user salting happening. I also created tw= o users, then dropped the database and created the same user accounts with = the same passwords again, and found that the resulting hashes were differen= t in both databases - thus there is something else ensuring the hashes are = unique across different installations/databases.

S= o, I believe we can do as you suggest and migrate existing values for SECUR= ITY_PASSWORD_SALT, given that there's clearly some other per user and p= er installation/database salting going on anyway. New installations can hav= e 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 - lo= oks good to me.
Please commit the new patch (if you're ok wit= h the change).


--

Thanks & Regards,

Ashesh Vashi
E= nterpriseDB INDIA:=C2=A0Enterprise PostgreSQL Company


<= /span>


I don't believe SECURITY_KEY and=C2=A0CSRF_SESS= ION_KEY are issues either, as they're used for purposes that are essent= ially ephemeral, and thus can be changed during an upgrade.

<= /div>
Adding Magnus as I'd appreciate any thoughts he may have.

Patch attached - please review (Ashesh, but others to= o would be appreciated)!

Thanks.


--
Dave Page
Blog: http://pgsnake.blogspot.comTwitter: @pgsnake

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





--
Dave Page
Bl= og: http://pgsnak= e.blogspot.com
Twitter: @pgsnake

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



--



--
Syed Fahar Abbas
Quality Management= Group

EnterpriseDB Corporation
Phone Office: +92-51-835-88= 74
Phone Direct: +92-51-8466803
Mobile: +92-333-5409707
Sk= ype ID: syed.fahar.abbas
Website: www.enterprisedb.com



--
=
Syed Fahar Abbas
Quality Management Group

E= nterpriseDB Corporation
Phone Office: +92-51-835-8874
Phone Direct: <= a href=3D"tel:%2B92-51-8466803" value=3D"+92518466803" target=3D"_blank">+9= 2-51-8466803
Mobile: +92-333-5409707
Skype ID: syed.fahar.ab= bas
Website: w= ww.enterprisedb.com




--
Syed Fahar Abbas
Quality Manage= ment Group

EnterpriseDB Corporation
Phone Office: +92-51-83= 5-8874
Phone Direct: +92-51-8466803
Mobile: +92-333-5409707
Skype = ID: syed.fahar.abbas
Website: www.enterprisedb.com
--001a114032942afa40053f35c1e2--