Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bx6B3-000605-LU for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 05:46:05 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bx6B2-0000Rw-PY for pgadmin-hackers@arkaria.postgresql.org; Thu, 20 Oct 2016 05:46:04 +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 1bx6B1-0000Rp-AU for pgadmin-hackers@postgresql.org; Thu, 20 Oct 2016 05:46:03 +0000 Received: from mail-qk0-x22b.google.com ([2607:f8b0:400d:c09::22b]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1bx6Aw-0004EE-7a for pgadmin-hackers@postgresql.org; Thu, 20 Oct 2016 05:46:02 +0000 Received: by mail-qk0-x22b.google.com with SMTP id n189so73006943qke.0 for ; Wed, 19 Oct 2016 22:45:57 -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=RBmrwOY1HPoIPpuNeSeVnebfoMhpW/5pHUAAxbmu5NY=; b=TOsCokkdb6o8Pisx3Ry8cPDcZWOXQGtTQz4OJ4VMfGjaW3Yway5CbLxYFG8jNX7CBK 8yjxkHWIRTCZVPO2H+MK2LSyk1QwXtW1wJyPtUuszxHNtTMAAAsQKxyeYP9fIIjV5JML Ug2I1uuzQlwVn/ZNeuXcFOFuHWtsXgpFGr3iMerMglJivG5qUidkZNTb1UrBYkUmRQu4 aF2wEaDY3P/u+WGvZqj3PVwPb7rGD1+wvt+xKsNa0A0BkxwJzvzVGYVLxuN8o4hBpkl0 2K4A69UJkCGNABDXTijauHfwOLnABCB70NgNK220Y8jSxPkOzOp9JSc7NwKLaKrQHU1c pgVA== 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=RBmrwOY1HPoIPpuNeSeVnebfoMhpW/5pHUAAxbmu5NY=; b=JgQpNwr83141L0uJhUpwd68GJWr9+255SfiSxzIvJF68ah7WheWUREK1WQA5KDFMRD miH4CQEnpBZyIdEYTKy43ifvYIN0mqJy1sjHTcRCIa9tTEXx/QQDrthvFhobqgPX80yM c+G9YI3qb685LUXbMEJN0K2iE3yl5Lqih9QEsjfOomwwyZyHznJb7kVfNyDJjQ3Gqv06 bn2mebTLFYVU7px+I+Mx5cj+pJtSNt5St/C0mATVsefeWrq7XpjUGBBTj+8UPJ/AGOr6 xm7lYkiNcesx6kbfPt5s8Ok4I3JOCVBBTwT9hw6oqzui1qdZPXOvkzZUNqElcwPTkFHl oqzQ== X-Gm-Message-State: AA6/9RkEJDtOZfjdpSK0dKKNl9D4gUIVirsbYvnErRbRQQS8p1gXhhYljDAZ5FCsxiN9sxCbJXZJTMEzoDOde09V X-Received: by 10.55.12.210 with SMTP id 201mr9301702qkm.292.1476942356247; Wed, 19 Oct 2016 22:45:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.130.133 with HTTP; Wed, 19 Oct 2016 22:45:35 -0700 (PDT) In-Reply-To: References: From: Murtuza Zabuawala Date: Thu, 20 Oct 2016 11:15:35 +0530 Message-ID: Subject: Re: RM1849: Auto-generating security keys To: Fahar Abbas Cc: Dave Page , Ashesh Vashi , pgadmin-hackers , Josh Berkus , =?UTF-8?B?RGV2cmltIEfDnE5Ew5xa?= , Magnus Hagander , Sandeep Thakkar , Hamid Quddus Akhtar Content-Type: multipart/mixed; boundary=94eb2c062cc67fa5a7053f4570e3 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 --94eb2c062cc67fa5a7053f4570e3 Content-Type: multipart/alternative; boundary=94eb2c062cc67fa5a2053f4570e1 --94eb2c062cc67fa5a2053f4570e1 Content-Type: text/plain; charset=UTF-8 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 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 > --94eb2c062cc67fa5a2053f4570e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

PFA patch to fix the issue for Pyht= on3.
RM#1849

=
--
Regards,
Murtuza Zabuawala
EnterpriseDB:=C2=A0http://www.enterprisedb.com
The Enterprise PostgreSQL Comp= any

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.org/issues/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@enterprisedb.com> wrote:
Hi Fahar,

Pl= ease log the case on redmine.
Please find the attached patch, please ap= ply it locally, and test it.

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

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise 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 <= span dir=3D"ltr"><fahar.abbas@enterprisedb.com> wrote:
Here is the output of if we cop= y config_local.py and execute python setup.py
pgAdmin 4 - Applicat= ion 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.d= b' does not exist.
Entering initial setup mode...
NOTE: Configuri= ng 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"
python setup.py
pgAd= min 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.<= span>


The configuration database - '/home/fahar/.pgadmi= n/pgadmin4.db' does not exist.
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 account:

Email address: fahar.abbas@enterprisedb= .com
Password:
Retype password:
Traceback (most recent call l= ast):
=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_s= ecurity/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_securit= y/utils.py", line 108, in get_hmac
=C2=A0=C2=A0=C2=A0 'set= to "%s"' % _security.password_hash)
RuntimeError: The con= figuration value `SECURITY_PASSWORD_SALT` must not be None when the value o= f `SECURITY_PASSWORD_HASH` is set to "pbkdf2_sha512"

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

Testing Environmen= t
=C2=A0
Ubuntu 16.04 Linux 64:
----------------------= ----------

pg-Admi= nIV 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 m= odule

sudo a= pt-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<= /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\pgAdm= in4\web=C2=A0=C2=A0

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


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:


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@enterprisedb.com> wrote:
Sure,

Will test this thor= oughly 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.

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

<= div class=3D"m_-5631392044300219617m_2500240099394767488m_-6843424418728108= 180m_-6366166414894557042m_8579966991770304932m_-4019292325802352314m_24368= 46264967577571gmail-h5">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, 20= 16, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
Hi Dav= e,

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

Can you please review the attached pat= ch, and apply if you're happy with it?
Overall t= he patch looked good to me.
But - I encounter an issue in 'we= b' mode, which wont happen with 'runtime'.

=
Steps for reproduction on existing pgAdmin 4 environment with 'web= ' mode.
- Apply the patch
- Start the pgAdmin4 appl= ication (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 ini= tializing the Security object.
Hence - it could not set the SECUR= ITY_KEY, and SECURITY_PASSWORD_SALT properly.

Hmm.
=C2=A0

I had moved the Security objec= t initialization after fetching these configurations from the database.
I have attached a addon patch for the same.
<= /blockquote>

OK, thanks.
=C2=A0

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

I think - we need to think about different strategy fo= r upgrading the configuration file in the 'web' mode.
I w= as thinking - we can store the existing security configurations in the data= base during upgrade process in 'web' mode.
<= /blockquote>

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

I guess what we need t= o 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 d= atabase which is clearly not a good idea. Sigh... Needs more thought.=C2=A0=

OK, so I've been thi= nking about this and experimenting for a couple of hours, as well as annoyi= ng the crap out of Magnus by thinking out loud in his general direction, an= d it looks like this isn'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-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 d= ifferent 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 re= sulting hashes were different in both databases - thus there is something e= lse ensuring the hashes are unique across different installations/databases= .

So, I believe we can do as you suggest and migra= te existing values for SECURITY_PASSWORD_SALT, given that there's clear= ly some other per user and per installation/database salting going on anywa= y. New installations can have the random value for SECURITY_PASSWORD_SALT.<= /div>
We do not need to generate the random SE= CURITY_PASSWORD_SALT during upgrade mode, which was wrong added in my addon= patch.

Please find the updated patch.
<= br>
Otherwise - looks good to me.
Please commit the new= patch (if you're ok with the change).


--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA:=C2=A0Enterprise PostgreSQL Company



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

Addin= g Magnus as I'd appreciate any thoughts he may have.

Patch attached - please review (Ashesh, but others too would be appr= eciated)!

Thanks.


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

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





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

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



--
Syed Fahar Ab= bas
Quality Management Group

EnterpriseDB Corpor= ation
Phone Office: +92-51-835-8874
Phone Direct: +92-51-8466803Mobile: +92-333-5409707
Skype ID: syed.fahar.abbas
Website: <= a href=3D"http://www.enterprisedb.com" target=3D"_blank">www.enterprisedb.c= om



--
Syed Fahar Abbas
Quality Management Gr= oup

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



--
Syed Fahar Abbas
Quality Management Group

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




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

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


--
Syed Fahar Abbas
Quality Management Group

EnterpriseDB Corporation
Phone Office: +92-51-835-8874
Phone Dire= ct: +92-51-8466803
Mobile: +92-333-5409707
Skype ID: syed.fahar.abbas=
Website: www.= enterprisedb.com
--94eb2c062cc67fa5a2053f4570e1-- --94eb2c062cc67fa5a7053f4570e3 Content-Type: application/octet-stream; name="python3_compatible.patch" Content-Disposition: attachment; filename="python3_compatible.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iuhxbdhy0 ZGlmZiAtLWdpdCBhL3dlYi9zZXR1cC5weSBiL3dlYi9zZXR1cC5weQppbmRl eCBjM2QzYjM2Li44MGIxMWZlIDEwMDc1NQotLS0gYS93ZWIvc2V0dXAucHkK KysrIGIvd2ViL3NldHVwLnB5CkBAIC0zNTAsMTcgKzM1MCwyMCBAQCBDUkVB VEUgVEFCTEUga2V5cyAoCiAgICAgUFJJTUFSWSBLRVkgKG5hbWUpKQogICAg ICAgICAgICAgICAgICIiIikKIAotICAgICAgICAgICAgc3FsID0gIklOU0VS VCBJTlRPIGtleXMgKG5hbWUsIHZhbHVlKSBWQUxVRVMgKCdDU1JGX1NFU1NJ T05fS0VZJywgJyVzJykiICUgYmFzZTY0LnVybHNhZmVfYjY0ZW5jb2RlKG9z LnVyYW5kb20oMzIpKQorICAgICAgICAgICAgc3FsID0gIklOU0VSVCBJTlRP IGtleXMgKG5hbWUsIHZhbHVlKSBWQUxVRVMgKCdDU1JGX1NFU1NJT05fS0VZ JywgJyVzJykiIFwKKyAgICAgICAgICAgICAgICAgICUgYmFzZTY0LnVybHNh ZmVfYjY0ZW5jb2RlKG9zLnVyYW5kb20oMzIpKS5kZWNvZGUoKQogICAgICAg ICAgICAgZGIuZW5naW5lLmV4ZWN1dGUoc3FsKQogCi0gICAgICAgICAgICBz cWwgPSAiSU5TRVJUIElOVE8ga2V5cyAobmFtZSwgdmFsdWUpIFZBTFVFUyAo J1NFQ1JFVF9LRVknLCAnJXMnKSIgJSBiYXNlNjQudXJsc2FmZV9iNjRlbmNv ZGUob3MudXJhbmRvbSgzMikpCisgICAgICAgICAgICBzcWwgPSAiSU5TRVJU IElOVE8ga2V5cyAobmFtZSwgdmFsdWUpIFZBTFVFUyAoJ1NFQ1JFVF9LRVkn LCAnJXMnKSIgJSBcCisgICAgICAgICAgICAgICAgICBiYXNlNjQudXJsc2Fm ZV9iNjRlbmNvZGUob3MudXJhbmRvbSgzMikpLmRlY29kZSgpCiAgICAgICAg ICAgICBkYi5lbmdpbmUuZXhlY3V0ZShzcWwpCiAKICAgICAgICAgICAgICMg SWYgU0VDVVJJVFlfUEFTU1dPUkRfU0FMVCBpcyBub3QgaW4gdGhlIGNvbmZp ZywgYnV0IHdlJ3JlIHVwZ3JhZGluZywgdGhlbiBpdCBtdXN0ICh1bmxlc3Mg dGhlCiAgICAgICAgICAgICAjIHVzZXIgZWRpdGVkIHRoZSBtYWluIGNvbmZp ZyAtIHdoaWNoIHRoZXkgc2hvdWxkbid0IGhhdmUgZG9uZSkgaGF2ZSBiZWVu IGF0IGl0J3MgZGVmYXVsdAogICAgICAgICAgICAgIyB2YWx1ZSwgc28gd2Un bGwgdXNlIHRoYXQuIE90aGVyd2lzZSwgdXNlIHdoYXRldmVyIHdlIGNhbiBm aW5kIGluIHRoZSBjb25maWcuCiAgICAgICAgICAgICBpZiBoYXNhdHRyKGNv bmZpZywgJ1NFQ1VSSVRZX1BBU1NXT1JEX1NBTFQnKToKLSAgICAgICAgICAg ICAgICBzcWwgPSAiSU5TRVJUIElOVE8ga2V5cyAobmFtZSwgdmFsdWUpIFZB TFVFUyAoJ1NFQ1VSSVRZX1BBU1NXT1JEX1NBTFQnLCAnJXMnKSIgJSBjb25m aWcuU0VDVVJJVFlfUEFTU1dPUkRfU0FMVAorICAgICAgICAgICAgICAgIHNx bCA9ICJJTlNFUlQgSU5UTyBrZXlzIChuYW1lLCB2YWx1ZSkgVkFMVUVTICgn U0VDVVJJVFlfUEFTU1dPUkRfU0FMVCcsICclcycpIiBcCisgICAgICAgICAg ICAgICAgICAgICAgJSBjb25maWcuU0VDVVJJVFlfUEFTU1dPUkRfU0FMVAog ICAgICAgICAgICAgZWxzZToKICAgICAgICAgICAgICAgICBzcWwgPSAiSU5T RVJUIElOVE8ga2V5cyAobmFtZSwgdmFsdWUpIFZBTFVFUyAoJ1NFQ1VSSVRZ X1BBU1NXT1JEX1NBTFQnLCAnU3VwZXJTZWNyZXQzJykiCiAgICAgICAgICAg ICBkYi5lbmdpbmUuZXhlY3V0ZShzcWwpCg== --94eb2c062cc67fa5a7053f4570e3 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers --94eb2c062cc67fa5a7053f4570e3--