pgAdmin 4 commit: 1. Add min width to panels.

[Akshay Joshi]

1. Add min width to panels.
2. Fix issues related to New connection in query tool. Also fixed some existing 
bugs related to this.

refs #6131

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=c5ca394cec5bd0fb117a2010eb99c07cef4540bc
Author: Aditya Toshniwal 

Modified Files
--
web/pgadmin/static/js/helpers/Layout.jsx   |   1 +
web/pgadmin/static/js/helpers/ModalProvider.jsx|  10 +-
web/pgadmin/tools/sqleditor/__init__.py|  17 +--
.../static/js/components/QueryToolComponent.jsx| 168 ++---
4 files changed, 130 insertions(+), 66 deletions(-)

Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source

[Aditya Toshniwal]

On Fri, Apr 22, 2022 at 3:57 PM Dave Page  wrote:

>
>
> On Fri, 22 Apr 2022 at 11:16, Aditya Toshniwal <
> aditya.toshni...@enterprisedb.com> wrote:
>
>>
>>
>> On Fri, Apr 22, 2022 at 3:28 PM Dave Page  wrote:
>>
>>>
>>>
>>> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal <
>>> aditya.toshni...@enterprisedb.com> wrote:
>>>
 Hi Dave,

 Generally, secure keys like API_KEYS and all are supposed to be set in
 env and are read by the app. Similar is the alternative encryption key.
 People can run their scripts to export those config vars.

>>>
>>> On the client side, yes. This is server side though. It's not uncommon
>>> on the server side to include hooks to allow key retrieval from external
>>> key management systems.
>>>
>> Even on the server side. Like the AWS auth keys, or DB passwords. We can
>> include hooks, not against it. Just discussing.
>>
>
> If you're using an AWS auth key on a server, then you're acting as a
> client for AWS - and DB passwords are a great example of why using a hook
> is a good thing; it's a very common request from users to have a secure way
> to retrieve credentials from an external service. Not to mention that a DB
> password is needed on the client side of a connection, not on the server
> side. On the server side, the database would query LDAP/Kerberos/whatever.
>
> A better example would be querying a key management service to unlock an
> encrypted disk or something like the service Bruce wrote for managing
> pgcrypto keys.
>

Got it. Thanks.

>
>
>
>>
>>>
>>>

 On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

>
>
> On Fri, Apr 22, 2022 at 2:34 PM Dave Page  wrote:
>
>>
>>
>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page  wrote:
>>>
 Hi

 On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
 akshay.jo...@enterprisedb.com> wrote:

> Thanks, the patch applied.
>
> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> Please find the attached patch to implement the feature #7012 -
>> Disable master password requirement when using alternative auth 
>> source
>>
>> When pgAdmin stores a connection password, it encrypts it using a
>> key that is formed either from the master password, or from the 
>> pgAdmin
>> login password for the user. In the case of auth methods such as 
>> OAuth,
>> Kerberos or Webserver, pgAdmin doesn't have access to anything 
>> long-lived
>> to form the encryption key from, hence it uses the master password. 
>> And if
>> the master is disabled, there is no way to store the connection 
>> password.
>>
>> To resolve this, we have added an option to config.py (which
>> defaults to None) for an alternate encryption key. pgAdmin would use 
>> this
>> if a) the master password is disabled AND b) there is no suitable
>> key/password available from the auth module for the user. If the
>> option is set to None, pgAdmin works as it does now.
>>
>
 This change has just been brought to my attention through other
 work. I think this is poorly thought out, and could easily be made much
 more secure and flexible than the current design.

 Instead of effectively hard-coding a master password, which is only
 slightly more secure than not having one in the first place, we should
 allow the user to specify the path to a script or program that will 
 return
 a key. In a security-conscious environment, the script might query a
 centralised key management system to securely retrieve the key to use. 
 If a
 user really wants the less secure implementation that this current 
 patch
 offers, then a simple script as follows would offer that (but would 
 not be
 recommended):

 
 #!/bin/sh

 echo "my secret key"
 

 We would probably also want to allow use of a placeholder in which
 the username can be passed, e.g.

 MASTER_ENCRYPTION_KEY_SCRIPT = '/path/to/get-key.sh %u'

 Sounds good to me.
>>> Does this mean we are going to remove the current implementation
>>> which offers a hard-coded master password?
>>>

>> Yes, I think that is the way to go. I don't want to add a config
>> parameter that doesn't seem like a good solution, and then remove it 
>> again
>> in the next release.
>>
>> Ok, In that case, we need to revert the patch and also 

Re: [pgAdmin][RM7322] Error Message displayed "Request failed with status code 503" if create new database on Windows only

[Akshay Joshi]

Thanks, the patch applied.

On Fri, Apr 22, 2022 at 7:37 AM Pradip Parkale <
pradip.park...@enterprisedb.com> wrote:

> Hi Hackers,
>
> You can find the attached patch for #7322. The error message "Request
> failed with status code 503" appears if you create a new database.
> I also solved their issue with the SQL panel being editable.
>
> --
> Thanks & Regards,
> Pradip Parkale
> Software Engineer | EnterpriseDB Corporation
>


-- 
*Thanks & Regards*
*Akshay Joshi*
*pgAdmin Hacker | Principal Software Architect*
*EDB Postgres *

*Mobile: +91 976-788-8246*

pgAdmin 4 commit: Revert "Disable the master password requirement when

[Akshay Joshi]

Revert "Disable the master password requirement when using alternative 
authentication sources. Fixes #7012"

This reverts commit 0c823455a0ee74fca2af08abae10186b3733990d.

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=faff8d1fb31967624e7cdb1c46c9ec237e30aaef

Modified Files
--
docs/en_US/alternate_encryption_key.rst | 33 -
docs/en_US/connecting.rst   |  7 ---
docs/en_US/master_password.rst  | 18 --
docs/en_US/release_notes_6_9.rst|  1 -
web/config.py   | 21 -
web/pgadmin/browser/__init__.py |  3 +--
web/pgadmin/utils/master_password.py|  3 ---
7 files changed, 9 insertions(+), 77 deletions(-)

pgAdmin 4 commit: Fixed an issue while creating a new database throwing

[Akshay Joshi]

Fixed an issue while creating a new database throwing an error that failed to 
retrieve data. Fixes #7322

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=ab8e9a8ea5ac2ef60b08c808f559349d37cd2e17
Author: Pradip Parkale 

Modified Files
--
docs/en_US/release_notes_6_9.rst   |  1 +
web/pgadmin/browser/static/js/panel.js |  2 +-
web/pgadmin/browser/static/js/panel_view.jsx   |  2 +
.../misc/properties/CollectionNodeProperties.jsx   |  8 +++-
web/pgadmin/misc/sql/static/js/SQL.jsx | 48 +++---
.../misc/statistics/static/js/Statistics.jsx   |  6 +--
6 files changed, 37 insertions(+), 30 deletions(-)

Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source

[Dave Page]

On Fri, 22 Apr 2022 at 11:16, Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

>
>
> On Fri, Apr 22, 2022 at 3:28 PM Dave Page  wrote:
>
>>
>>
>> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal <
>> aditya.toshni...@enterprisedb.com> wrote:
>>
>>> Hi Dave,
>>>
>>> Generally, secure keys like API_KEYS and all are supposed to be set in
>>> env and are read by the app. Similar is the alternative encryption key.
>>> People can run their scripts to export those config vars.
>>>
>>
>> On the client side, yes. This is server side though. It's not uncommon on
>> the server side to include hooks to allow key retrieval from external key
>> management systems.
>>
> Even on the server side. Like the AWS auth keys, or DB passwords. We can
> include hooks, not against it. Just discussing.
>

If you're using an AWS auth key on a server, then you're acting as a client
for AWS - and DB passwords are a great example of why using a hook is a
good thing; it's a very common request from users to have a secure way to
retrieve credentials from an external service. Not to mention that a DB
password is needed on the client side of a connection, not on the server
side. On the server side, the database would query LDAP/Kerberos/whatever.

A better example would be querying a key management service to unlock an
encrypted disk or something like the service Bruce wrote for managing
pgcrypto keys.



>
>>
>>
>>>
>>> On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On Fri, Apr 22, 2022 at 2:34 PM Dave Page  wrote:

>
>
> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page  wrote:
>>
>>> Hi
>>>
>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
>>> akshay.jo...@enterprisedb.com> wrote:
>>>
 Thanks, the patch applied.

 On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

> Hi,
>
> Please find the attached patch to implement the feature #7012 -
> Disable master password requirement when using alternative auth source
>
> When pgAdmin stores a connection password, it encrypts it using a
> key that is formed either from the master password, or from the 
> pgAdmin
> login password for the user. In the case of auth methods such as 
> OAuth,
> Kerberos or Webserver, pgAdmin doesn't have access to anything 
> long-lived
> to form the encryption key from, hence it uses the master password. 
> And if
> the master is disabled, there is no way to store the connection 
> password.
>
> To resolve this, we have added an option to config.py (which
> defaults to None) for an alternate encryption key. pgAdmin would use 
> this
> if a) the master password is disabled AND b) there is no suitable
> key/password available from the auth module for the user. If the
> option is set to None, pgAdmin works as it does now.
>

>>> This change has just been brought to my attention through other
>>> work. I think this is poorly thought out, and could easily be made much
>>> more secure and flexible than the current design.
>>>
>>> Instead of effectively hard-coding a master password, which is only
>>> slightly more secure than not having one in the first place, we should
>>> allow the user to specify the path to a script or program that will 
>>> return
>>> a key. In a security-conscious environment, the script might query a
>>> centralised key management system to securely retrieve the key to use. 
>>> If a
>>> user really wants the less secure implementation that this current patch
>>> offers, then a simple script as follows would offer that (but would not 
>>> be
>>> recommended):
>>>
>>> 
>>> #!/bin/sh
>>>
>>> echo "my secret key"
>>> 
>>>
>>> We would probably also want to allow use of a placeholder in which
>>> the username can be passed, e.g.
>>>
>>> MASTER_ENCRYPTION_KEY_SCRIPT = '/path/to/get-key.sh %u'
>>>
>>> Sounds good to me.
>> Does this mean we are going to remove the current implementation
>> which offers a hard-coded master password?
>>
>>>
> Yes, I think that is the way to go. I don't want to add a config
> parameter that doesn't seem like a good solution, and then remove it again
> in the next release.
>
> Ok, In that case, we need to revert the patch and also need to update
 the RM #7012 regarding our proposal.

>
> --
> Dave Page
> Blog: https://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EDB: https://www.enterprisedb.com
>
>
>>>
>>> --
>>> Thanks,
>>> 

Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source

[Ashesh Vashi]

On Fri, Apr 22, 2022 at 3:46 PM Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

>
>
> On Fri, Apr 22, 2022 at 3:28 PM Dave Page  wrote:
>
>>
>>
>> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal <
>> aditya.toshni...@enterprisedb.com> wrote:
>>
>>> Hi Dave,
>>>
>>> Generally, secure keys like API_KEYS and all are supposed to be set in
>>> env and are read by the app. Similar is the alternative encryption key.
>>> People can run their scripts to export those config vars.
>>>
>>
>> On the client side, yes. This is server side though. It's not uncommon on
>> the server side to include hooks to allow key retrieval from external key
>> management systems.
>>
> Even on the server side. Like the AWS auth keys, or DB passwords. We can
> include hooks, not against it. Just discussing.
>
Environment variables are good for static values.
Here - we're talking about dynamic data (per user security key), hence -
hooks are the best way forward.

-- Ashesh

>
>>
>>
>>>
>>> On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On Fri, Apr 22, 2022 at 2:34 PM Dave Page  wrote:

>
>
> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page  wrote:
>>
>>> Hi
>>>
>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
>>> akshay.jo...@enterprisedb.com> wrote:
>>>
 Thanks, the patch applied.

 On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

> Hi,
>
> Please find the attached patch to implement the feature #7012 -
> Disable master password requirement when using alternative auth source
>
> When pgAdmin stores a connection password, it encrypts it using a
> key that is formed either from the master password, or from the 
> pgAdmin
> login password for the user. In the case of auth methods such as 
> OAuth,
> Kerberos or Webserver, pgAdmin doesn't have access to anything 
> long-lived
> to form the encryption key from, hence it uses the master password. 
> And if
> the master is disabled, there is no way to store the connection 
> password.
>
> To resolve this, we have added an option to config.py (which
> defaults to None) for an alternate encryption key. pgAdmin would use 
> this
> if a) the master password is disabled AND b) there is no suitable
> key/password available from the auth module for the user. If the
> option is set to None, pgAdmin works as it does now.
>

>>> This change has just been brought to my attention through other
>>> work. I think this is poorly thought out, and could easily be made much
>>> more secure and flexible than the current design.
>>>
>>> Instead of effectively hard-coding a master password, which is only
>>> slightly more secure than not having one in the first place, we should
>>> allow the user to specify the path to a script or program that will 
>>> return
>>> a key. In a security-conscious environment, the script might query a
>>> centralised key management system to securely retrieve the key to use. 
>>> If a
>>> user really wants the less secure implementation that this current patch
>>> offers, then a simple script as follows would offer that (but would not 
>>> be
>>> recommended):
>>>
>>> 
>>> #!/bin/sh
>>>
>>> echo "my secret key"
>>> 
>>>
>>> We would probably also want to allow use of a placeholder in which
>>> the username can be passed, e.g.
>>>
>>> MASTER_ENCRYPTION_KEY_SCRIPT = '/path/to/get-key.sh %u'
>>>
>>> Sounds good to me.
>> Does this mean we are going to remove the current implementation
>> which offers a hard-coded master password?
>>
>>>
> Yes, I think that is the way to go. I don't want to add a config
> parameter that doesn't seem like a good solution, and then remove it again
> in the next release.
>
> Ok, In that case, we need to revert the patch and also need to update
 the RM #7012 regarding our proposal.

>
> --
> Dave Page
> Blog: https://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EDB: https://www.enterprisedb.com
>
>
>>>
>>> --
>>> Thanks,
>>> Aditya Toshniwal
>>> pgAdmin Hacker | Software Architect | *edbpostgres.com*
>>> 
>>> "Don't Complain about Heat, Plant a TREE"
>>>
>>
>>
>> --
>> Dave Page
>> Blog: https://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EDB: https://www.enterprisedb.com
>>
>>
>
> --
> Thanks,
> Aditya Toshniwal
> pgAdmin Hacker | Software Architect | *edbpostgres.com*
> 
> "Don't Complain about Heat, 

Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source

[Aditya Toshniwal]

On Fri, Apr 22, 2022 at 3:28 PM Dave Page  wrote:

>
>
> On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal <
> aditya.toshni...@enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>> Generally, secure keys like API_KEYS and all are supposed to be set in
>> env and are read by the app. Similar is the alternative encryption key.
>> People can run their scripts to export those config vars.
>>
>
> On the client side, yes. This is server side though. It's not uncommon on
> the server side to include hooks to allow key retrieval from external key
> management systems.
>
Even on the server side. Like the AWS auth keys, or DB passwords. We can
include hooks, not against it. Just discussing.

>
>
>
>>
>> On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page  wrote:
>>>


 On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

>
>
> On Fri, Apr 22, 2022 at 2:01 PM Dave Page  wrote:
>
>> Hi
>>
>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
>> akshay.jo...@enterprisedb.com> wrote:
>>
>>> Thanks, the patch applied.
>>>
>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>
 Hi,

 Please find the attached patch to implement the feature #7012 -
 Disable master password requirement when using alternative auth source

 When pgAdmin stores a connection password, it encrypts it using a
 key that is formed either from the master password, or from the pgAdmin
 login password for the user. In the case of auth methods such as OAuth,
 Kerberos or Webserver, pgAdmin doesn't have access to anything 
 long-lived
 to form the encryption key from, hence it uses the master password. 
 And if
 the master is disabled, there is no way to store the connection 
 password.

 To resolve this, we have added an option to config.py (which
 defaults to None) for an alternate encryption key. pgAdmin would use 
 this
 if a) the master password is disabled AND b) there is no suitable
 key/password available from the auth module for the user. If the
 option is set to None, pgAdmin works as it does now.

>>>
>> This change has just been brought to my attention through other work.
>> I think this is poorly thought out, and could easily be made much more
>> secure and flexible than the current design.
>>
>> Instead of effectively hard-coding a master password, which is only
>> slightly more secure than not having one in the first place, we should
>> allow the user to specify the path to a script or program that will 
>> return
>> a key. In a security-conscious environment, the script might query a
>> centralised key management system to securely retrieve the key to use. 
>> If a
>> user really wants the less secure implementation that this current patch
>> offers, then a simple script as follows would offer that (but would not 
>> be
>> recommended):
>>
>> 
>> #!/bin/sh
>>
>> echo "my secret key"
>> 
>>
>> We would probably also want to allow use of a placeholder in which
>> the username can be passed, e.g.
>>
>> MASTER_ENCRYPTION_KEY_SCRIPT = '/path/to/get-key.sh %u'
>>
>> Sounds good to me.
> Does this mean we are going to remove the current implementation which
> offers a hard-coded master password?
>
>>
 Yes, I think that is the way to go. I don't want to add a config
 parameter that doesn't seem like a good solution, and then remove it again
 in the next release.

 Ok, In that case, we need to revert the patch and also need to update
>>> the RM #7012 regarding our proposal.
>>>

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

 EDB: https://www.enterprisedb.com


>>
>> --
>> Thanks,
>> Aditya Toshniwal
>> pgAdmin Hacker | Software Architect | *edbpostgres.com*
>> 
>> "Don't Complain about Heat, Plant a TREE"
>>
>
>
> --
> Dave Page
> Blog: https://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EDB: https://www.enterprisedb.com
>
>

-- 
Thanks,
Aditya Toshniwal
pgAdmin Hacker | Software Architect | *edbpostgres.com*

"Don't Complain about Heat, Plant a TREE"

Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source

[Dave Page]

On Fri, 22 Apr 2022 at 10:49, Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

> Hi Dave,
>
> Generally, secure keys like API_KEYS and all are supposed to be set in env
> and are read by the app. Similar is the alternative encryption key.
> People can run their scripts to export those config vars.
>

On the client side, yes. This is server side though. It's not uncommon on
the server side to include hooks to allow key retrieval from external key
management systems.



>
> On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Fri, Apr 22, 2022 at 2:34 PM Dave Page  wrote:
>>
>>>
>>>
>>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On Fri, Apr 22, 2022 at 2:01 PM Dave Page  wrote:

> Hi
>
> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
> akshay.jo...@enterprisedb.com> wrote:
>
>> Thanks, the patch applied.
>>
>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> Hi,
>>>
>>> Please find the attached patch to implement the feature #7012 -
>>> Disable master password requirement when using alternative auth source
>>>
>>> When pgAdmin stores a connection password, it encrypts it using a
>>> key that is formed either from the master password, or from the pgAdmin
>>> login password for the user. In the case of auth methods such as OAuth,
>>> Kerberos or Webserver, pgAdmin doesn't have access to anything 
>>> long-lived
>>> to form the encryption key from, hence it uses the master password. And 
>>> if
>>> the master is disabled, there is no way to store the connection 
>>> password.
>>>
>>> To resolve this, we have added an option to config.py (which
>>> defaults to None) for an alternate encryption key. pgAdmin would use 
>>> this
>>> if a) the master password is disabled AND b) there is no suitable
>>> key/password available from the auth module for the user. If the
>>> option is set to None, pgAdmin works as it does now.
>>>
>>
> This change has just been brought to my attention through other work.
> I think this is poorly thought out, and could easily be made much more
> secure and flexible than the current design.
>
> Instead of effectively hard-coding a master password, which is only
> slightly more secure than not having one in the first place, we should
> allow the user to specify the path to a script or program that will return
> a key. In a security-conscious environment, the script might query a
> centralised key management system to securely retrieve the key to use. If 
> a
> user really wants the less secure implementation that this current patch
> offers, then a simple script as follows would offer that (but would not be
> recommended):
>
> 
> #!/bin/sh
>
> echo "my secret key"
> 
>
> We would probably also want to allow use of a placeholder in which the
> username can be passed, e.g.
>
> MASTER_ENCRYPTION_KEY_SCRIPT = '/path/to/get-key.sh %u'
>
> Sounds good to me.
 Does this mean we are going to remove the current implementation which
 offers a hard-coded master password?

>
>>> Yes, I think that is the way to go. I don't want to add a config
>>> parameter that doesn't seem like a good solution, and then remove it again
>>> in the next release.
>>>
>>> Ok, In that case, we need to revert the patch and also need to update
>> the RM #7012 regarding our proposal.
>>
>>>
>>> --
>>> Dave Page
>>> Blog: https://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EDB: https://www.enterprisedb.com
>>>
>>>
>
> --
> Thanks,
> Aditya Toshniwal
> pgAdmin Hacker | Software Architect | *edbpostgres.com*
> 
> "Don't Complain about Heat, Plant a TREE"
>


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

EDB: https://www.enterprisedb.com

Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source

[Aditya Toshniwal]

Hi Dave,

Generally, secure keys like API_KEYS and all are supposed to be set in env
and are read by the app. Similar is the alternative encryption key.
People can run their scripts to export those config vars.

On Fri, Apr 22, 2022 at 2:38 PM Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Fri, Apr 22, 2022 at 2:34 PM Dave Page  wrote:
>
>>
>>
>> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page  wrote:
>>>
 Hi

 On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
 akshay.jo...@enterprisedb.com> wrote:

> Thanks, the patch applied.
>
> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> Please find the attached patch to implement the feature #7012 -
>> Disable master password requirement when using alternative auth source
>>
>> When pgAdmin stores a connection password, it encrypts it using a key
>> that is formed either from the master password, or from the pgAdmin login
>> password for the user. In the case of auth methods such as OAuth, 
>> Kerberos
>> or Webserver, pgAdmin doesn't have access to anything long-lived to form
>> the encryption key from, hence it uses the master password. And if the
>> master is disabled, there is no way to store the connection password.
>>
>> To resolve this, we have added an option to config.py (which defaults
>> to None) for an alternate encryption key. pgAdmin would use this if a) 
>> the
>> master password is disabled AND b) there is no suitable key/password
>> available from the auth module for the user. If the option is set to
>> None, pgAdmin works as it does now.
>>
>
 This change has just been brought to my attention through other work. I
 think this is poorly thought out, and could easily be made much more secure
 and flexible than the current design.

 Instead of effectively hard-coding a master password, which is only
 slightly more secure than not having one in the first place, we should
 allow the user to specify the path to a script or program that will return
 a key. In a security-conscious environment, the script might query a
 centralised key management system to securely retrieve the key to use. If a
 user really wants the less secure implementation that this current patch
 offers, then a simple script as follows would offer that (but would not be
 recommended):

 
 #!/bin/sh

 echo "my secret key"
 

 We would probably also want to allow use of a placeholder in which the
 username can be passed, e.g.

 MASTER_ENCRYPTION_KEY_SCRIPT = '/path/to/get-key.sh %u'

 Sounds good to me.
>>> Does this mean we are going to remove the current implementation which
>>> offers a hard-coded master password?
>>>

>> Yes, I think that is the way to go. I don't want to add a config
>> parameter that doesn't seem like a good solution, and then remove it again
>> in the next release.
>>
>> Ok, In that case, we need to revert the patch and also need to update the
> RM #7012 regarding our proposal.
>
>>
>> --
>> Dave Page
>> Blog: https://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EDB: https://www.enterprisedb.com
>>
>>

-- 
Thanks,
Aditya Toshniwal
pgAdmin Hacker | Software Architect | *edbpostgres.com*

"Don't Complain about Heat, Plant a TREE"

Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source

[Khushboo Vashi]

On Fri, Apr 22, 2022 at 2:34 PM Dave Page  wrote:

>
>
> On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Fri, Apr 22, 2022 at 2:01 PM Dave Page  wrote:
>>
>>> Hi
>>>
>>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi <
>>> akshay.jo...@enterprisedb.com> wrote:
>>>
 Thanks, the patch applied.

 On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

> Hi,
>
> Please find the attached patch to implement the feature #7012 -
> Disable master password requirement when using alternative auth source
>
> When pgAdmin stores a connection password, it encrypts it using a key
> that is formed either from the master password, or from the pgAdmin login
> password for the user. In the case of auth methods such as OAuth, Kerberos
> or Webserver, pgAdmin doesn't have access to anything long-lived to form
> the encryption key from, hence it uses the master password. And if the
> master is disabled, there is no way to store the connection password.
>
> To resolve this, we have added an option to config.py (which defaults
> to None) for an alternate encryption key. pgAdmin would use this if a) the
> master password is disabled AND b) there is no suitable key/password
> available from the auth module for the user. If the option is set to
> None, pgAdmin works as it does now.
>

>>> This change has just been brought to my attention through other work. I
>>> think this is poorly thought out, and could easily be made much more secure
>>> and flexible than the current design.
>>>
>>> Instead of effectively hard-coding a master password, which is only
>>> slightly more secure than not having one in the first place, we should
>>> allow the user to specify the path to a script or program that will return
>>> a key. In a security-conscious environment, the script might query a
>>> centralised key management system to securely retrieve the key to use. If a
>>> user really wants the less secure implementation that this current patch
>>> offers, then a simple script as follows would offer that (but would not be
>>> recommended):
>>>
>>> 
>>> #!/bin/sh
>>>
>>> echo "my secret key"
>>> 
>>>
>>> We would probably also want to allow use of a placeholder in which the
>>> username can be passed, e.g.
>>>
>>> MASTER_ENCRYPTION_KEY_SCRIPT = '/path/to/get-key.sh %u'
>>>
>>> Sounds good to me.
>> Does this mean we are going to remove the current implementation which
>> offers a hard-coded master password?
>>
>>>
> Yes, I think that is the way to go. I don't want to add a config parameter
> that doesn't seem like a good solution, and then remove it again in the
> next release.
>
> Ok, In that case, we need to revert the patch and also need to update the
RM #7012 regarding our proposal.

>
> --
> Dave Page
> Blog: https://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EDB: https://www.enterprisedb.com
>
>

Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source

[Dave Page]

On Fri, 22 Apr 2022 at 09:57, Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Fri, Apr 22, 2022 at 2:01 PM Dave Page  wrote:
>
>> Hi
>>
>> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi 
>> wrote:
>>
>>> Thanks, the patch applied.
>>>
>>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>
 Hi,

 Please find the attached patch to implement the feature #7012 - Disable
 master password requirement when using alternative auth source

 When pgAdmin stores a connection password, it encrypts it using a key
 that is formed either from the master password, or from the pgAdmin login
 password for the user. In the case of auth methods such as OAuth, Kerberos
 or Webserver, pgAdmin doesn't have access to anything long-lived to form
 the encryption key from, hence it uses the master password. And if the
 master is disabled, there is no way to store the connection password.

 To resolve this, we have added an option to config.py (which defaults
 to None) for an alternate encryption key. pgAdmin would use this if a) the
 master password is disabled AND b) there is no suitable key/password
 available from the auth module for the user. If the option is set to
 None, pgAdmin works as it does now.

>>>
>> This change has just been brought to my attention through other work. I
>> think this is poorly thought out, and could easily be made much more secure
>> and flexible than the current design.
>>
>> Instead of effectively hard-coding a master password, which is only
>> slightly more secure than not having one in the first place, we should
>> allow the user to specify the path to a script or program that will return
>> a key. In a security-conscious environment, the script might query a
>> centralised key management system to securely retrieve the key to use. If a
>> user really wants the less secure implementation that this current patch
>> offers, then a simple script as follows would offer that (but would not be
>> recommended):
>>
>> 
>> #!/bin/sh
>>
>> echo "my secret key"
>> 
>>
>> We would probably also want to allow use of a placeholder in which the
>> username can be passed, e.g.
>>
>> MASTER_ENCRYPTION_KEY_SCRIPT = '/path/to/get-key.sh %u'
>>
>> Sounds good to me.
> Does this mean we are going to remove the current implementation which
> offers a hard-coded master password?
>
>>
Yes, I think that is the way to go. I don't want to add a config parameter
that doesn't seem like a good solution, and then remove it again in the
next release.


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

EDB: https://www.enterprisedb.com

Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source

[Khushboo Vashi]

On Fri, Apr 22, 2022 at 2:01 PM Dave Page  wrote:

> Hi
>
> On Mon, 11 Apr 2022 at 09:20, Akshay Joshi 
> wrote:
>
>> Thanks, the patch applied.
>>
>> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> Hi,
>>>
>>> Please find the attached patch to implement the feature #7012 - Disable
>>> master password requirement when using alternative auth source
>>>
>>> When pgAdmin stores a connection password, it encrypts it using a key
>>> that is formed either from the master password, or from the pgAdmin login
>>> password for the user. In the case of auth methods such as OAuth, Kerberos
>>> or Webserver, pgAdmin doesn't have access to anything long-lived to form
>>> the encryption key from, hence it uses the master password. And if the
>>> master is disabled, there is no way to store the connection password.
>>>
>>> To resolve this, we have added an option to config.py (which defaults to
>>> None) for an alternate encryption key. pgAdmin would use this if a) the
>>> master password is disabled AND b) there is no suitable key/password
>>> available from the auth module for the user. If the option is set to
>>> None, pgAdmin works as it does now.
>>>
>>
> This change has just been brought to my attention through other work. I
> think this is poorly thought out, and could easily be made much more secure
> and flexible than the current design.
>
> Instead of effectively hard-coding a master password, which is only
> slightly more secure than not having one in the first place, we should
> allow the user to specify the path to a script or program that will return
> a key. In a security-conscious environment, the script might query a
> centralised key management system to securely retrieve the key to use. If a
> user really wants the less secure implementation that this current patch
> offers, then a simple script as follows would offer that (but would not be
> recommended):
>
> 
> #!/bin/sh
>
> echo "my secret key"
> 
>
> We would probably also want to allow use of a placeholder in which the
> username can be passed, e.g.
>
> MASTER_ENCRYPTION_KEY_SCRIPT = '/path/to/get-key.sh %u'
>
> Sounds good to me.
Does this mean we are going to remove the current implementation which
offers a hard-coded master password?

> --
> Dave Page
> Blog: https://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EDB: https://www.enterprisedb.com
>
>

Re: [pgAdmin4][Patch]- Feature #7012 - disable master password requirement when using alternative auth source

[Dave Page]

Hi

On Mon, 11 Apr 2022 at 09:20, Akshay Joshi 
wrote:

> Thanks, the patch applied.
>
> On Mon, Apr 11, 2022 at 12:00 PM Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> Please find the attached patch to implement the feature #7012 - Disable
>> master password requirement when using alternative auth source
>>
>> When pgAdmin stores a connection password, it encrypts it using a key
>> that is formed either from the master password, or from the pgAdmin login
>> password for the user. In the case of auth methods such as OAuth, Kerberos
>> or Webserver, pgAdmin doesn't have access to anything long-lived to form
>> the encryption key from, hence it uses the master password. And if the
>> master is disabled, there is no way to store the connection password.
>>
>> To resolve this, we have added an option to config.py (which defaults to
>> None) for an alternate encryption key. pgAdmin would use this if a) the
>> master password is disabled AND b) there is no suitable key/password
>> available from the auth module for the user. If the option is set to
>> None, pgAdmin works as it does now.
>>
>
This change has just been brought to my attention through other work. I
think this is poorly thought out, and could easily be made much more secure
and flexible than the current design.

Instead of effectively hard-coding a master password, which is only
slightly more secure than not having one in the first place, we should
allow the user to specify the path to a script or program that will return
a key. In a security-conscious environment, the script might query a
centralised key management system to securely retrieve the key to use. If a
user really wants the less secure implementation that this current patch
offers, then a simple script as follows would offer that (but would not be
recommended):


#!/bin/sh

echo "my secret key"


We would probably also want to allow use of a placeholder in which the
username can be passed, e.g.

MASTER_ENCRYPTION_KEY_SCRIPT = '/path/to/get-key.sh %u'

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

EDB: https://www.enterprisedb.com