Thread: Using postgresql.org account as an auth id on third party websites

     Hi list.

     AFAIK what I ask in $SUBJECT is available and used on some 
websites, but is this documented? Is it based in Oauth2?

     It would be great to know more details :) Thanks,

     Álvaro

-- 

Alvaro Hernandez


-----------
OnGres

On 2019-09-17 14:00, Álvaro Hernández wrote:
>     Hi list.
> 
>     AFAIK what I ask in $SUBJECT is available and used on some
> websites, but is this documented? Is it based in Oauth2?
> 
>     It would be great to know more details :) Thanks,

Agreed, this would be useful. :)

+ Justin

Hi Alvaro,

On 9/17/19 12:00 AM, Álvaro Hernández wrote:
>
>     Hi list.
>
>     AFAIK what I ask in $SUBJECT is available and used on some websites,
> but is this documented? Is it based in Oauth2?
>
>     It would be great to know more details :) Thanks,

The documentation for it is here:

https://git.postgresql.org/gitweb/?p=pgweb.git;a=blob_plain;f=docs/authentication.rst;hb=HEAD

Note that a site that wishes to use community authentication still needs
to be registered with the central system. For testing purposes, you will
likely need to set up your own copy of pgweb.

Thanks!

Jonathan

On 17/9/19 5:58, Jonathan S. Katz wrote:
> Hi Alvaro,
>
> On 9/17/19 12:00 AM, Álvaro Hernández wrote:
>>      Hi list.
>>
>>      AFAIK what I ask in $SUBJECT is available and used on some websites,
>> but is this documented? Is it based in Oauth2?
>>
>>      It would be great to know more details :) Thanks,
> The documentation for it is here:
>
> https://git.postgresql.org/gitweb/?p=pgweb.git;a=blob_plain;f=docs/authentication.rst;hb=HEAD
>
> Note that a site that wishes to use community authentication still needs
> to be registered with the central system. For testing purposes, you will
> likely need to set up your own copy of pgweb.
>
> Thanks!
>
> Jonathan
>

     Great, thank you Jonathan.

     Now.... how do we register with the "central system"?


     Álvaro

-- 

Alvaro Hernandez


-----------
OnGres

On 9/17/19 11:54 AM, Álvaro Hernández wrote:
>
>
>     Great, thank you Jonathan.
>
>     Now.... how do we register with the "central system"?

Well, first make sure that it works :)

I've not handled the registration process myself, but to test it, ensure
you can authenticate against the test pgweb instance you've set up. You
can configure it from the "Community auth sites" and "community auth
orgs" part of the admin. So once that works, I think there can be the
conversation of actually registering with the "central system."

To date, apps that use community auth have been within pginfra (AFAICT),
so to "formally request" it probably involves a longer conversation,
either here or with webmaster@ as the process of doing so has not been
exercised yet.

Thanks,

Jonathan

On 17/9/19 14:14, Jonathan S. Katz wrote:
> On 9/17/19 11:54 AM, Álvaro Hernández wrote:
>>
>>      Great, thank you Jonathan.
>>
>>      Now.... how do we register with the "central system"?
> Well, first make sure that it works :)
>
> I've not handled the registration process myself, but to test it, ensure
> you can authenticate against the test pgweb instance you've set up. You
> can configure it from the "Community auth sites" and "community auth
> orgs" part of the admin. So once that works, I think there can be the
> conversation of actually registering with the "central system."

     We can do that, no problem.

>
> To date, apps that use community auth have been within pginfra (AFAICT),
> so to "formally request" it probably involves a longer conversation,
> either here or with webmaster@ as the process of doing so has not been
> exercised yet.

     Fair enough. Now.... I'd like not to waste any resources before 
having that "longer conversation" then, which I hope it is not that 
long. We're building a user authentication system on top of 
https://postgresqlco.nf that will use external id providers like Google 
Account, Twitter and others. We'd like to provide postgresql.org 
community account as a first-class citizen authentication mechanism, 
since this is something for the PostgreSQL Community as a whole. If this 
is possible, great! If not, we should know asap and stick with the other 
providers only --but I hope should not be a big deal.


     Thanks,

     Álvaro

-- 

Alvaro Hernandez


-----------
OnGres

On Wed, Sep 18, 2019 at 12:25 AM Álvaro Hernández <aht@ongres.com> wrote:

On 17/9/19 14:14, Jonathan S. Katz wrote:
> On 9/17/19 11:54 AM, Álvaro Hernández wrote:
>>
>>      Great, thank you Jonathan.
>>
>>      Now.... how do we register with the "central system"?
> Well, first make sure that it works :)
>
> I've not handled the registration process myself, but to test it, ensure
> you can authenticate against the test pgweb instance you've set up. You
> can configure it from the "Community auth sites" and "community auth
> orgs" part of the admin. So once that works, I think there can be the
> conversation of actually registering with the "central system."

     We can do that, no problem.

>
> To date, apps that use community auth have been within pginfra (AFAICT),
> so to "formally request" it probably involves a longer conversation,
> either here or with webmaster@ as the process of doing so has not been
> exercised yet.

     Fair enough. Now.... I'd like not to waste any resources before
having that "longer conversation" then, which I hope it is not that
long. We're building a user authentication system on top of
https://postgresqlco.nf that will use external id providers like Google
Account, Twitter and others. We'd like to provide postgresql.org
community account as a first-class citizen authentication mechanism,
since this is something for the PostgreSQL Community as a whole. If this
is possible, great! If not, we should know asap and stick with the other
providers only --but I hope should not be a big deal.
 

So far, we have only approved services running fully managed by the infrastructure team to handle this. Some of them are managed by different organisations (such as PostgreSQL Europe or PostgreSQL US), but since they are running on the main infrastructure there the team has the ability to reach and manage all the data.

Right now, the system isn't really set up to handle things outside of that, as some things (particularly in relation to our new friend the gdpr) are handled completely manually and are not in the system. There are a number of things that should be implemented before doing something like that, such as the ability to push out a forced account delete (no API for that now). Or at the very least, a second level of consent about sharing data in an irretrievable way.

    Hi Magnus.

    You mention that this mechanism is already approved for different organisations. Indeed, this is where I saw it in action and loved the idea! But if it is approved for third-party (from a legal perspective) organisations, I don't see why it would not be for other third-party organisations. You mention GDPR and, if anything, that they are running "on the main infrastructure" (i.e. the infrastructure of a separate legal entity, I assume the PostgreSQL Canada Association) seems like something which may have serious GDPR issues on its own. I understand how things are down when being built, but have a look just in case ;)

    But back on topic, on what concerns my request: let's open this up to any third party organisation --it has already been done. I don't see why having "the team the ability to manage all the data" changes anything. What I'm requesting access to is a system for third-party authentication, similar to "login with Google" or any other auth provider. There's no "forced account delete" mechanism that I'm aware of, and there is little to no information sharing other than "hey, please authenticate this person and let me know the boolean information of whether that was successful or not" (optionally request name and email, as other authentication providers do, that is PII, but that's it). What auth providers do is a way to force delete a session (an authentication token, which typically expires quickly, but could be forcibly expired). This is optional, and in no way would force any deletion on the third party (it is the user who should use the third party's account deletion procedures).

    In summary: it is already opened to third parties, please help us get to use it too, it's a very cool thing ;)


    Álvaro

-- 

Alvaro Hernandez


-----------
OnGres

Greetings,

* Magnus Hagander (magnus@hagander.net) wrote:
> On Wed, Sep 18, 2019 at 12:25 AM Álvaro Hernández <aht@ongres.com> wrote:
> > On 17/9/19 14:14, Jonathan S. Katz wrote:
> >      Fair enough. Now.... I'd like not to waste any resources before
> > having that "longer conversation" then, which I hope it is not that
> > long. We're building a user authentication system on top of
> > https://postgresqlco.nf that will use external id providers like Google
> > Account, Twitter and others. We'd like to provide postgresql.org
> > community account as a first-class citizen authentication mechanism,
> > since this is something for the PostgreSQL Community as a whole. If this
> > is possible, great! If not, we should know asap and stick with the other
> > providers only --but I hope should not be a big deal.
>
> So far, we have only approved services running fully managed by the
> infrastructure team to handle this. Some of them are managed by different
> organisations (such as PostgreSQL Europe or PostgreSQL US), but since they
> are running on the main infrastructure there the team has the ability to
> reach and manage all the data.

I'd also point out that those other organizations are recognized
Community Non-Profits, and/or running Community recognized conferences.
That isn't an explicit 'policy' about what we run on pginfra or what
pginfra manages or is willing to tie things into, just to be clear, but
I do think it provides a good set of examples.

> Right now, the system isn't really set up to handle things outside of that,
> as some things (particularly in relation to our new friend the gdpr) are
> handled completely manually and are not in the system. There are a number
> of things that should be implemented before doing something like that, such
> as the ability to push out a forced account delete (no API for that now).
> Or at the very least, a second level of consent about sharing data in an
> irretrievable way.

Yes, there's some technical bits too, but that might be something we
could work out a solution to.

Thanks,

Stephen

Greetings,

* Álvaro Hernández (aht@ongres.com) wrote:
>     You mention that this mechanism is already approved for different
> organisations. Indeed, this is where I saw it in action and loved the idea!
> But if it is approved for third-party (from a legal perspective)
> organisations, I don't see why it would not be for other third-party
> organisations. You mention GDPR and, if anything, that they are running "on
> the main infrastructure" (i.e. the infrastructure of a separate legal
> entity, I assume the PostgreSQL Canada Association) seems like something
> which may have serious GDPR issues on its own. I understand how things are
> down when being built, but have a look just in case ;)

If you believe there's a specific GDPR concern regarding what we're
doing, it'd be great if you could help us explain more clearly what that
concern is.

>     But back on topic, on what concerns my request: let's open this up to
> any third party organisation --it has already been done. I don't see why
> having "the team the ability to manage all the data" changes anything. What
> I'm requesting access to is a system for third-party authentication, similar
> to "login with Google" or any other auth provider. There's no "forced
> account delete" mechanism that I'm aware of, and there is little to no
> information sharing other than "hey, please authenticate this person and let
> me know the boolean information of whether that was successful or not"
> (optionally request name and email, as other authentication providers do,
> that is PII, but that's it). What auth providers do is a way to force delete
> a session (an authentication token, which typically expires quickly, but
> could be forcibly expired). This is optional, and in no way would force any
> deletion on the third party (it is the user who should use the third party's
> account deletion procedures).

I don't agree that we should open this up to just any third party
organization to use.  There's specific, recognized, organizations, who
also run on pginfra, who have been allowed to leverage this system but
saying that, say, Google, could use it, or any other organization
represents a de-facto endorsement of those systems which isn't something
that I think we, as a project, should be doing.

>     In summary: it is already opened to third parties, please help us get to
> use it too, it's a very cool thing ;)

Those are very specific third parties which have requirements set on
them through our policies, not anyone, so this argument isn't valid.

Thanks,

Stephen

On 18/9/19 9:08, Stephen Frost wrote:
> Greetings,
>
> * Magnus Hagander (magnus@hagander.net) wrote:
>> On Wed, Sep 18, 2019 at 12:25 AM Álvaro Hernández <aht@ongres.com> wrote:
>>> On 17/9/19 14:14, Jonathan S. Katz wrote:
>>>       Fair enough. Now.... I'd like not to waste any resources before
>>> having that "longer conversation" then, which I hope it is not that
>>> long. We're building a user authentication system on top of
>>> https://postgresqlco.nf that will use external id providers like Google
>>> Account, Twitter and others. We'd like to provide postgresql.org
>>> community account as a first-class citizen authentication mechanism,
>>> since this is something for the PostgreSQL Community as a whole. If this
>>> is possible, great! If not, we should know asap and stick with the other
>>> providers only --but I hope should not be a big deal.
>> So far, we have only approved services running fully managed by the
>> infrastructure team to handle this. Some of them are managed by different
>> organisations (such as PostgreSQL Europe or PostgreSQL US), but since they
>> are running on the main infrastructure there the team has the ability to
>> reach and manage all the data.
> I'd also point out that those other organizations are recognized
> Community Non-Profits, and/or running Community recognized conferences.
> That isn't an explicit 'policy' about what we run on pginfra or what
> pginfra manages or is willing to tie things into, just to be clear, but
> I do think it provides a good set of examples.

     If there isn't such a policy, TBQH I don't think this is an example 
of anything. And if there would be a policy, I believe that being a 
Community Non-Profit and/or running a Community conference should not be 
requisites for being able to use postgresql.org login. Why should they 
be related at all? If anything, this is about providing *conveniency* 
for PostgreSQL users to log into third party services without having to 
depend on other third party authentication providers which whom those 
users may feel less comfortable.

     FWIW I also organize a Community Recognized Conference 
(https://pgibz.io).

>
>> Right now, the system isn't really set up to handle things outside of that,
>> as some things (particularly in relation to our new friend the gdpr) are
>> handled completely manually and are not in the system. There are a number
>> of things that should be implemented before doing something like that, such
>> as the ability to push out a forced account delete (no API for that now).
>> Or at the very least, a second level of consent about sharing data in an
>> irretrievable way.
> Yes, there's some technical bits too, but that might be something we
> could work out a solution to.

     Good, I'm all ears. But I'm still surprised that technical bits are 
not required for PostgreSQL EU / US, they are separate entities and 
those bits (at least from a legal perspective) should apply equally.


     Álvaro

-- 

Alvaro Hernandez


-----------
OnGres

Greetings,

* Álvaro Hernández (aht@ongres.com) wrote:
> On 18/9/19 9:08, Stephen Frost wrote:
> >I'd also point out that those other organizations are recognized
> >Community Non-Profits, and/or running Community recognized conferences.
> >That isn't an explicit 'policy' about what we run on pginfra or what
> >pginfra manages or is willing to tie things into, just to be clear, but
> >I do think it provides a good set of examples.
>
>     If there isn't such a policy, TBQH I don't think this is an example of
> anything. And if there would be a policy, I believe that being a Community
> Non-Profit and/or running a Community conference should not be requisites
> for being able to use postgresql.org login. Why should they be related at
> all? If anything, this is about providing *conveniency* for PostgreSQL users
> to log into third party services without having to depend on other third
> party authentication providers which whom those users may feel less
> comfortable.

I addressed this- having that tie-in is a de-facto endorsement of it.

>     FWIW I also organize a Community Recognized Conference
> (https://pgibz.io).

Great!  Perhaps if it was hosted on pginfra then we could have it
included as part of the auth system.

>     Good, I'm all ears. But I'm still surprised that technical bits are not
> required for PostgreSQL EU / US, they are separate entities and those bits
> (at least from a legal perspective) should apply equally.

The technical bits are around who manages the systems, not around what
the organizations are.  If you'd like us to host postgresqlco.nf, that'd
be a seperate discussion.

Thanks,

Stephen

On 18/9/19 9:13, Stephen Frost wrote:
> Greetings,
>
> * Álvaro Hernández (aht@ongres.com) wrote:
>>      You mention that this mechanism is already approved for different
>> organisations. Indeed, this is where I saw it in action and loved the idea!
>> But if it is approved for third-party (from a legal perspective)
>> organisations, I don't see why it would not be for other third-party
>> organisations. You mention GDPR and, if anything, that they are running "on
>> the main infrastructure" (i.e. the infrastructure of a separate legal
>> entity, I assume the PostgreSQL Canada Association) seems like something
>> which may have serious GDPR issues on its own. I understand how things are
>> down when being built, but have a look just in case ;)
> If you believe there's a specific GDPR concern regarding what we're
> doing, it'd be great if you could help us explain more clearly what that
> concern is.

     It's not really my concern, but more of a recommendation: just 
review if all is good. If data from Postgres EU is managed by 
infrastructure and staff from another organisation (PostgreSQL 
Association in Canada) there should be several issues at play like: a 
clear contract for services provision among the entities; clear policies 
on how information is exchanged (and if postgresql.org login cannot be 
opened to third parties as some data cancellation mechanisms are not in 
place, this is a red flag IMHO that those mechanisms are not in place 
right now for the EU Association); and possibly others. I'm not a GDPR 
expert, but I'd recommend to review this. It sounds to me that things 
are too intertwined between different orgs, where one is non EU. Clear 
boundaries are required. I may be of course wrong and all this is 
already in place.

>
>>      But back on topic, on what concerns my request: let's open this up to
>> any third party organisation --it has already been done. I don't see why
>> having "the team the ability to manage all the data" changes anything. What
>> I'm requesting access to is a system for third-party authentication, similar
>> to "login with Google" or any other auth provider. There's no "forced
>> account delete" mechanism that I'm aware of, and there is little to no
>> information sharing other than "hey, please authenticate this person and let
>> me know the boolean information of whether that was successful or not"
>> (optionally request name and email, as other authentication providers do,
>> that is PII, but that's it). What auth providers do is a way to force delete
>> a session (an authentication token, which typically expires quickly, but
>> could be forcibly expired). This is optional, and in no way would force any
>> deletion on the third party (it is the user who should use the third party's
>> account deletion procedures).
> I don't agree that we should open this up to just any third party
> organization to use.  There's specific, recognized, organizations, who

     Why not?

     I don't know any other third-party authentication provider that 
does impose any limitation or requisite (other than checking for legal 
existence etc).

> also run on pginfra, who have been allowed to leverage this system but
> saying that, say, Google, could use it, or any other organization
> represents a de-facto endorsement of those systems which isn't something
> that I think we, as a project, should be doing.

     Just make it clear that the system does not come with a guaranteed 
SLA if that's your concern and that's fine. Use at your own risk, no 
guarantees of availability. Fine!


>
>>      In summary: it is already opened to third parties, please help us get to
>> use it too, it's a very cool thing ;)
> Those are very specific third parties which have requirements set on
> them through our policies, not anyone, so this argument isn't valid.

     Now what you say reads to me that there are some "privileged" 
entities. I'd like to know more, why and how they are privileged. Can 
you post here that policies that you mention? I may want to apply to be 
privileged too ;P


     Thanks,

     Álvaro

-- 

Alvaro Hernandez


-----------
OnGres

On 18/9/19 9:20, Stephen Frost wrote:
> Greetings,
>
> * Álvaro Hernández (aht@ongres.com) wrote:
>> On 18/9/19 9:08, Stephen Frost wrote:
>>> I'd also point out that those other organizations are recognized
>>> Community Non-Profits, and/or running Community recognized conferences.
>>> That isn't an explicit 'policy' about what we run on pginfra or what
>>> pginfra manages or is willing to tie things into, just to be clear, but
>>> I do think it provides a good set of examples.
>>      If there isn't such a policy, TBQH I don't think this is an example of
>> anything. And if there would be a policy, I believe that being a Community
>> Non-Profit and/or running a Community conference should not be requisites
>> for being able to use postgresql.org login. Why should they be related at
>> all? If anything, this is about providing *conveniency* for PostgreSQL users
>> to log into third party services without having to depend on other third
>> party authentication providers which whom those users may feel less
>> comfortable.
> I addressed this- having that tie-in is a de-facto endorsement of it.

     I see this more of a problem than a benefit, specially in the face 
of GDPR, but also as a general principle. There are several entities at 
play, there should be clear boundaries established.

>
>>      FWIW I also organize a Community Recognized Conference
>> (https://pgibz.io).
> Great!  Perhaps if it was hosted on pginfra then we could have it
> included as part of the auth system.

     That would be very cool. What do we need to do?

>
>>      Good, I'm all ears. But I'm still surprised that technical bits are not
>> required for PostgreSQL EU / US, they are separate entities and those bits
>> (at least from a legal perspective) should apply equally.
> The technical bits are around who manages the systems, not around what
> the organizations are.  If you'd like us to host postgresqlco.nf, that'd
> be a seperate discussion.

     I believe postgresqlco.nf is not a good fit for this use case, but 
thanks :) Still, I want to understand:

a) why having intertwined systems is a good and not a bad thing
b) why this cannot be opened to any other third party (policy) and what 
is (technically) limiting it


     Regards,

     Álvaro

-- 

Alvaro Hernandez


-----------
OnGres

On Wed, Sep 18, 2019 at 5:16 PM Álvaro Hernández <aht@ongres.com> wrote:

On 18/9/19 3:45, Magnus Hagander wrote:

On Wed, Sep 18, 2019 at 12:25 AM Álvaro Hernández <aht@ongres.com> wrote:

On 17/9/19 14:14, Jonathan S. Katz wrote:
> On 9/17/19 11:54 AM, Álvaro Hernández wrote:
>>
>>      Great, thank you Jonathan.
>>
>>      Now.... how do we register with the "central system"?
> Well, first make sure that it works :)
>
> I've not handled the registration process myself, but to test it, ensure
> you can authenticate against the test pgweb instance you've set up. You
> can configure it from the "Community auth sites" and "community auth
> orgs" part of the admin. So once that works, I think there can be the
> conversation of actually registering with the "central system."

     We can do that, no problem.

>
> To date, apps that use community auth have been within pginfra (AFAICT),
> so to "formally request" it probably involves a longer conversation,
> either here or with webmaster@ as the process of doing so has not been
> exercised yet.

     Fair enough. Now.... I'd like not to waste any resources before
having that "longer conversation" then, which I hope it is not that
long. We're building a user authentication system on top of
https://postgresqlco.nf that will use external id providers like Google
Account, Twitter and others. We'd like to provide postgresql.org
community account as a first-class citizen authentication mechanism,
since this is something for the PostgreSQL Community as a whole. If this
is possible, great! If not, we should know asap and stick with the other
providers only --but I hope should not be a big deal.
 

So far, we have only approved services running fully managed by the infrastructure team to handle this. Some of them are managed by different organisations (such as PostgreSQL Europe or PostgreSQL US), but since they are running on the main infrastructure there the team has the ability to reach and manage all the data.

Right now, the system isn't really set up to handle things outside of that, as some things (particularly in relation to our new friend the gdpr) are handled completely manually and are not in the system. There are a number of things that should be implemented before doing something like that, such as the ability to push out a forced account delete (no API for that now). Or at the very least, a second level of consent about sharing data in an irretrievable way.

    Hi Magnus.

    You mention that this mechanism is already approved for different organisations. Indeed, this is where I saw it in action and loved the idea! But if it is approved for third-party (from a legal perspective) organisations, I don't see why it would not be for other third-party organisations. You mention GDPR and, if anything, that they are running "on the main infrastructure" (i.e. the infrastructure of a separate legal entity, I assume the PostgreSQL Canada Association) seems like something which may have serious GDPR issues on its own. I understand how things are down when being built, but have a look just in case ;)

Then your assumption is wrong.

    I would not like to be otherwise. But I dunno. What you described seemed to me like PII and possibly other data, handled by different legal entities, under different jurisdictions (laws), is managed by the same group of people and shared, with no clear boundaries. I could be totally wrong, but I believe something might not be totally right there.

    Anyway, no worries: this is offtopic, I feel good I gave my feedback, I hope it helped (if at all to revisit this) and I would feel even better if all is absolutely correct. You are the President of EU, not me, so this is as far as I can get ;)

Also note that my only mention of GDPR was in relation to there being things related to that which are manual.

    But back on topic, on what concerns my request: let's open this up to any third party organisation --it has already been done. I don't see why having "the team the ability to manage all the data" changes anything. What I'm requesting access to is a system for third-party authentication, similar to "login with Google" or any other auth provider. There's no "forced account delete" mechanism that I'm aware of, and there is little to no information sharing other than "hey, please authenticate this person and let me know the boolean information of whether that was successful or not" (optionally request name and email, as other authentication providers do, that is PII, but that's it). What auth providers do is a way to force delete a session (an authentication token, which typically expires quickly, but could be forcibly expired). This is optional, and in no way would force any deletion on the third party (it is the user who should use the third party's account deletion procedures).

Just because Google does something one way, doesn't mean that we want to do it that way. We are allowed to treat our users better than Google treat their tracking-victims for example, and would like to 

stick to that level.

    I used Google as an example. You came back with an unrelated, Google rant (????).

Oh, and as a general rule, "requesting" unpaid volunteers to do work for you for free is in general not a great way to get them enthusiastic about helping out.

    Did I do so? I don't recall where or when I said that.

    Irrespective of this: what you say I read as:

- Either volunteers, due to being unpaid, are not doing their job correctly (completely);
- or we do not have enough volunteers (which might, in turn, be the consequence of them being unpaid).

    AFAIK:

- PostgreSQL holds $142,000 on SPI of which less than $10,000 are allocated for use (https://wiki.postgresql.org/wiki/PgCon_2019_Developer_Meeting#09:35_-_09:40.09Funds_.26_Sponsors_update).
- PostgreSQL EU had by 2018's years end more than $200,000 in cash (https://www.postgresql.eu/about/ga/2019/financialreport/).
- PostgreSQL US has, as far as I know, half an order of magnitude more cash than EU.

    So... are we doing the right thing here, letting all this infrastructure be run by unpaid volunteers? Don't get me wrong, I applaud volunteers work and I love that some things are run by volunteers (and most of them/you are good friends, thank you!). But specially if the lack of extra hands *is holding progress back*, we're doing a poor job by not using the resources that PostgreSQL has (and more than I'm sure could be raised if needed) to move more things *forward* and *faster*.

    In summary: it is already opened to third parties, please help us get to use it too, it's a very cool thing ;)

In summary, it is open to third parties *running on our managed infrastructure*.  That is a huge difference.

    I understand the difference between running on the same managed infrastructure or not. But I don't understand --because despite the already lengthy thread nobody has stated what the reasons are-- why this factor makes a difference. Is the auth server a web service? Where it runs? What kind of authentication does it use that relies on the same managed infrastructure? It uses SSL certificates emitted by a custom CA? I can think of many things, please exemplify.

>      If there isn't such a policy, TBQH I don't think this is an example
> of anything. And if there would be a policy, I believe that being a
> Community Non-Profit and/or running a Community conference should not be 
> requisites for being able to use postgresql.org login. Why should they 

> be related at all? If anything, this is about providing *conveniency* 

> for PostgreSQL users to log into third party services without having to
> depend on other third party authentication providers which whom those
> users may feel less comfortable.

Why should they *not* be related? Again, this is a service provided for free by volunteers. I'm pretty sure it's up to those volunteers to decide what to do with their time.

    Because there shouldn't be a difference whether this service, which is already provided, is provided for a third party (that happens to run on one location) or provided to another third party (that happens to run on a possibly distinct location). Nobody is questioning volunteers work.

> FWIW I also organize a Community Recognized Conference  (https://pgibz.io).

And I like that!

But you did not ask for this service for that conference. You asked for it for a different site, run by ongres. So I'm not sure how that suddenly became relevant?

    It became relevant when Stephen raised this and made it relevant. I only responded because I always try to respond to every concern raised.

> Good, I'm all ears. But I'm still surprised that technical bits are
> not required for PostgreSQL EU / US, they are separate entities and
> those bits (at least from a legal perspective) should apply equally.

As already answered, that is because those things

    "those". What things? You are all talking in the abstract. You may have the context, I don't. I cannot understand without more precise details, I'm sorry.

are currently handled manually, and they can only be handled manually if the people dealing with them have full access to every part of every system that's in the mesh. Which means that they run on our managed infrastructure. It would certainly be better if that wasn't manual handling, but that's how it is right now.

Had the PGEU/PGUS systems run outside our infrastructure they would have the same requirements. And had your service been running on the infrastructure, it would not.

That part is at this point a technical problem. And in fact, it's definitely one we'd like to see solved *regardless* of if it's opened up to external access or not (because it's bloody annoying even when they are on the same infra).

Would you be interested in working on that and providing a patch that can be discussed/considered?

    Please let us know what needs to be changed, if it is code (and what code), infrastructure, whatever. I'm interested in providing help, given that it is within our area of expertise.

And with that fixed, we'd want at least a second level of consent (one similar to how for example Google does it today, since you like to compare to them), where you get a clear warning when you leave to an unrelated site. Are you interested in working on that and providing a patch that can be discussed/considered for that?

    I'm surprised this second level of consent is not required for pgconf.eu. Can you explain why it is required for one use case and not for another use case.... when both uses cases happen to be the *same*?

One thing that could probably be done easier, since it would be easier to gain user acceptance on, would be if only the authentication and not the sharing part were opened up. In that case, the external system would receive the "yes this account is logged in" along with non-personal identifier for that account (such as a uuid or hash), but not the PI. If all you're looking for is  alogin system, then perhaps that would be enough? (It would certainly be a lot less work to implement)

    I like iterative approach to problems. This is better than nothing, but I still cannot understand what the problem is and what the different level of effort is required. Does pgconf.eu get any PII from the user login? If so, it should be done already.

> I don't know any other third-party authentication provider that
> does impose any limitation or requisite (other than checking for legal 
> existence etc).

postgresql.org is not an authentication provider, so you cannot compare to that. In regards to how the community authentication system works today it is also not a third party, so you cannot compare to that either. So that comparison is entirely invlaid.

    postgresql.org, run by the PostgreSQL Association of Canada, is an authentication provider for some services run by other different entities (like the PostgreSQL EU Association in France). So why it cannot authenticate other third parties? There is no difference at all (or there should not be).

> Just make it clear that the system does not come with a guaranteed
> SLA if that's your concern and that's fine. Use at your own risk, no
> guarantees of availability. Fine!

I'm sure you are well aware that is not how reality works.

When things don't work, people will complain. Somebody will be spending time dealing with those complaints.

For example, just the other day I spent quite a bit of time debugging a case of an account with conflicting email addresses caused by changing multiple accounts between different email addresses. I was able to do this, because I had full access to the systems on either side and could check the constraints. Who will be doing that if there is no access and no technical solution for deadling with it?

    Correctness, legal compliance and equal provision of capabilities to any third parties sometimes requires the development of processes. Maybe some process needs to be developed here. Even if it would be more time consuming (which I doubt, if properly streamlined and designed). Because what you say sounds to me as:

- You are conflating roles, entities and concerns into peoples and entities that should be separate. This IMVHO needs to be fixed regardless of this discussion.
- There are very few people in your position (with access to the full infra of both PostgreSQL CA and EU) and that may become (maybe is already, apparently) a bottleneck. If concerns were appropriately separated, many other people could be on either side and given a process among them, it would be fixed easily and promptly.

    But anyway, I'm still puzzled by the level of tight coupling. An auth provider does not need to have any interaction from the consumer of the authentication service *at all* to operate. It is, indeed, one of its basic principles of operation.

You also compare it to places like Google -- and it's true, their SLA is "you're on your own". So basically, why are we even responding to your questions on this thread?

    Really, what do you mean? You don't need to reply to me if you don't want...

None of the other authentication providers you mention would do that.

You may be happy to drop the SLA level to "ignore your users", but as that would have an effect on existing users as well, no, some of us are not OK with doing that.

    What I know is that not providing a service is worse than providing a service with best effort guarantees, specially if it is not something extremely demanding or used as of today, as it is the case.

We can of course say there's no availability on an integration to your specific one. Heck, we can say that already now -- make up a crypto key and run with it -- the redirects will still work, you don't even need us to input anything! But I'm pretty sure that would also draw complaints.

    What draws complaints is that there appears to be here "privileged" entities and not privileged entities.

>I may want to apply to be privileged too ;P

I am not sure what you refer to by privileged here, but you are certainly welcome to volunteer. Approximately how many hours per week can you commit to?

    Refer above to the $ argument. Let's hire someone. I'm willing to donate money if there would be not enough funds for this.

> I believe postgresqlco.nf is not a good fit for this use case, but
> thanks :) Still, I want to understand:

Why is it not?

    postgresqlco.nf is a free service, developed and run by OnGres. I don't think is a good fit to run on a non-profit entity's infrastructure. Is PostgreSQL infra providing hosting services for companies?

> a) why having intertwined systems is a good and not a bad thing

Who said the systems are intertwined? You are again making assumptions without facts.

    I make assumptions based on the information that was provided in this thread, which with the lack of other context sounds like there is a lot of intertwined systems. I'm happy to stand corrected if more information is provided.

In fact, had they *been* intertwined it would've been a lot easier to deal with the particular problems we have now. (For example, look at how the previous version of community auth was done years ago)

> b) why this cannot be opened to any other third party (policy) and what
> is (technically) limiting it

This has been answered, repeatedly.

    Not at all. Not a single tech reason has been provided.


    All in all: I wanted to provide PostgreSQL Community login because I felt it was a good thing for the PostgreSQL Community. For us, it means extra development effort where we have estimated that very few people, if anyone, would use. Most people are happy with *either* (Google or Twitter or GitHub or GitLab), which are the other auth providers we are implementing. So the only reason we wanted to provide this is to bring back here (as we do in many other areas) by "promoting" the use of the PostgreSQL Community account, to create a broader sense of Community. That services provided by the Community are available to the Community through a Community authentication system, and not relying on external providers like Google, given that we have one.

    Now if this causes this reaction against it, and it's that problematic, we will just simply forget about it and focus our efforts in other areas. But it honestly leave a very bitter taste: there appears to be some PostgreSQL Community services that are quite exclusive --in the literal sense of exclusiveness; and not the inclusiveness I'd expect from the PostgreSQL Community.


    Regards,

    Álvaro

-- 

Alvaro Hernandez


-----------
OnGres

On 9/20/19 3:14 AM, Álvaro Hernández wrote:
> 
> 


[...]

>>
>> Oh, and as a general rule, "requesting" unpaid volunteers to do work
>> for you for free is in general not a great way to get them
>> enthusiastic about helping out.
> 
>     Did I do so? I don't recall where or when I said that.
> 
>     Irrespective of this: what you say I read as:
> 
> - Either volunteers, due to being unpaid, are not doing their job
> correctly (completely);

tbh as one of those volunteers, I kinda find it pretty irritating that
that the very first time somebody asks for community auth being opened
to non-pginfra managed sites an association of "us" not doing our job
correctly comes up just because that feature does not (and/or is not
implemented in the way you want it) do like.


> - or we do not have enough volunteers (which might, in turn, be the
> consequence of them being unpaid).

well again, there can always be more volunteers, but this discussion
seems to go the wrong way anyway.

When software and systems are designed one always considers various
usecases and scenarios - and whether you are paid for doing so or not
you have to make decisions and tradeoffs. There is no such thing as
designing for every possible usecase and ultimate flexibility and yet
still delivering an actual production service - and that is what we are
looking at here. Community Auth as we have it now is already a
next-generation service compared to what we had in the past (as already
said on the thread but it was never designed nor does we want it to be a
global authentication service for everything.
If _you_ want such a service feel free to propose patches to enable it
to be (suggestions on what needs to be done have been given on the
thread already) but consider the fact that we might not want to add even
more external dependencies on pginfra than we already have...


> 
>     AFAIK:
> 
> - PostgreSQL holds $142,000 on SPI of which less than $10,000 are
> allocated for use
> (https://wiki.postgresql.org/wiki/PgCon_2019_Developer_Meeting#09:35_-_09:40.09Funds_.26_Sponsors_update).
> 
> - PostgreSQL EU had by 2018's years end more than $200,000 in cash
> (https://www.postgresql.eu/about/ga/2019/financialreport/).
> - PostgreSQL US has, as far as I know, half an order of magnitude more
> cash than EU.

aha

> 
>     So... are we doing the right thing here, letting all this
> infrastructure be run by unpaid volunteers? Don't get me wrong, I
> applaud volunteers work and I love that some things are run by
> volunteers (and most of them/you are good friends, thank you!). But
> specially if the lack of extra hands *is holding progress back*, we're
> doing a poor job by not using the resources that PostgreSQL has (and
> more than I'm sure could be raised if needed) to move more things
> *forward* and *faster*.

so we are a few days into a discussion on enabling community auth for
non-pginfra managed services (which has never been done before) and your
analysis is already that we are "holding progress back"? Again I
consider that pretty offensive and demanding especially since there has
not been shown any evidence (to me at least) that doing this would
actually be "progress" and would allow things to move "forward"
(whatever "forward" might mean in that case). _You_ are asking for
something new and never done nor needed before - so implying it is
somebody elses "fault" seems weird - to say the least.


> 
> 
>>
>>
>>         In summary: it is already opened to third parties, please help
>>     us get to use it too, it's a very cool thing ;)
>>
>>
>> In summary, it is open to third parties *running on our managed
>> infrastructure*.  That is a huge difference.
> 
>     I understand the difference between running on the same managed
> infrastructure or not. But I don't understand --because despite the
> already lengthy thread nobody has stated what the reasons are-- why this
> factor makes a difference. Is the auth server a web service? Where it
> runs? What kind of authentication does it use that relies on the same
> managed infrastructure? It uses SSL certificates emitted by a custom CA?
> I can think of many things, please exemplify.

Among others - It was never designed for this use case in mind, it has
not been documented for this usecase and nobody has investigated any
time (yet) in actually making this supportable and maintainable in the
context of entirely third parties. Doing all this implies both on-time
effort and ongoing long term effort (if we do this with completely
external entities we also need to do long-term support of both the
infrastructure and the code) and again, postgresql.org is not a general
auth provider nor do we want to be one - so it is up to you to put
forward a workable proposal (and no - claiming this would enable
"progress" is not that).


> 
>>
>>
>> >      If there isn't such a policy, TBQH I don't think this is an
>> example
>> > of anything. And if there would be a policy, I believe that being a
>> > Community Non-Profit and/or running a Community conference should
>> not be
>> > requisites for being able to use postgresql.org
>> <http://postgresql.org> login. Why should they
>> > be related at all? If anything, this is about providing *conveniency*
>> > for PostgreSQL users to log into third party services without having to
>> > depend on other third party authentication providers which whom those
>> > users may feel less comfortable.
>>
>> Why should they *not* be related? Again, this is a service provided
>> for free by volunteers. I'm pretty sure it's up to those volunteers to
>> decide what to do with their time.
> 
>     Because there shouldn't be a difference whether this service, which
> is already provided, is provided for a third party (that happens to run
> on one location) or provided to another third party (that happens to run
> on a possibly distinct location). Nobody is questioning volunteers work.

it _is_ entirely different to run this service within pginfra or
providing it to external entities - whether you believe that or not is
up to you but it is a fact...


[...]
> 
>     All in all: I wanted to provide PostgreSQL Community login because I
> felt it was a good thing for the PostgreSQL Community. For us, it means
> extra development effort where we have estimated that very few people,
> if anyone, would use. Most people are happy with *either* (Google or
> Twitter or GitHub or GitLab), which are the other auth providers we are
> implementing. So the only reason we wanted to provide this is to bring
> back here (as we do in many other areas) by "promoting" the use of the
> PostgreSQL Community account, to create a broader sense of Community.
> That services provided by the Community are available to the Community
> through a Community authentication system, and not relying on external
> providers like Google, given that we have one.

well you have nnot stated the "broader community" argument before, and
while I in fact see some merit in it - it is still a fact that the
current service has not been designed with that goal in mind , neither
from a code perspective nor is pginfra as team prepared for providing
this kinda of service to entirely external entities from a management
perspective.

> 
>     Now if this causes this reaction against it, and it's that
> problematic, we will just simply forget about it and focus our efforts
> in other areas. But it honestly leave a very bitter taste: there appears
> to be some PostgreSQL Community services that are quite exclusive --in
> the literal sense of exclusiveness; and not the inclusiveness I'd expect
> from the PostgreSQL Community.

Again - suggestions for code additions have been put forward, but as you
say people have to focus their efforts - the focus of community auth as
we have it now was not what you seem to want _now_.




Stefan

On 21/9/19 12:32, Stefan Kaltenbrunner wrote:
> On 9/20/19 3:14 AM, Álvaro Hernández wrote:
>>
>
> [...]
>
>>> Oh, and as a general rule, "requesting" unpaid volunteers to do work
>>> for you for free is in general not a great way to get them
>>> enthusiastic about helping out.
>>      Did I do so? I don't recall where or when I said that.
>>
>>      Irrespective of this: what you say I read as:
>>
>> - Either volunteers, due to being unpaid, are not doing their job
>> correctly (completely);
> tbh as one of those volunteers, I kinda find it pretty irritating that
> that the very first time somebody asks for community auth being opened
> to non-pginfra managed sites an association of "us" not doing our job
> correctly comes up just because that feature does not (and/or is not
> implemented in the way you want it) do like.

     TBQH, I'm having a really hard time to understand how this 
conclusion could be derived from my words. But it doesn't matter, it's 
my bad anyway if I made you, or anyone else, feel this way.

     For the avoidance of doubt: Stefan, and any other pg-infra 
volunteer or anyone else how felt bad about my words: my deepest and 
most sincere apology. I never, under any circumstance, intended to do 
any negative statement about the job done or the team itself. I have a 
great deal of respect to any kind of volunteering in general, let alone 
for the one on helping on the technology that I love. I have volunteered 
tons of work on Postgres myself, and I cannot otherwise that feel in the 
same page. pg-infra: I know the work that you do and have done, and I 
really appreciate it, specially given how small team you are.

     On the contrary: if anything, what I wanted to say is that why 
pg-infra is unpaid and relying on volunteers to do the job, specially 
when there are economic resources? Why don't we combine volunteer work 
with paid jobs to maintain pg-infra *and help it do more things*? The 
fact that there are enough economic resources (and more that could be 
raised if needed), some of which remain unallocated year after year, if 
anything, signals a failure in precisely allocating them to the best 
possible uses. And one of them could be to augment the current pg-infra 
team.
>
>
>> - or we do not have enough volunteers (which might, in turn, be the
>> consequence of them being unpaid).
> well again, there can always be more volunteers, but this discussion
> seems to go the wrong way anyway.

     Or complement the team with paid jobs.

>
> When software and systems are designed one always considers various
> usecases and scenarios - and whether you are paid for doing so or not
> you have to make decisions and tradeoffs. There is no such thing as
> designing for every possible usecase and ultimate flexibility and yet
> still delivering an actual production service - and that is what we are
> looking at here. Community Auth as we have it now is already a
> next-generation service compared to what we had in the past (as already
> said on the thread but it was never designed nor does we want it to be a
> global authentication service for everything.

     I take it that it was not designed as a global authentication 
service. But:

- I have asked repeatedly about technical details, nobody seems to 
provide. I only hear abstract terms that are mostly common sense, but no 
"meat". What are the limitations, what does it change that it runs on 
shared infra, is there any description of the service, etc, etc, etc?

- The infra belongs to (AFAIK) to the PostgreSQL Association of Canada 
(CA). As an example, the PostgreSQL Europe Association (EU) runs on CA's 
infra. Both are, from a legal perspective, different legal entities. 
Other than the possibly legal (is there a services contract among them?) 
and GDPR issues, which I just raised as a potential warning for 
something that might be revisited, why EU is (or needs to be) different 
from other entities in the PostgreSQL Community?

     I'd argue that specially the latter creates a privileged 
differentiation. If the service cannot be open globally, it should be 
open to no one. Since I won't obviously argue for this, I argue to work 
together and find a way to open it to third parties and fix this -from a 
legal perspective discriminating situation- asap.


> If _you_ want such a service feel free to propose patches to enable it
> to be (suggestions on what needs to be done have been given on the
> thread already) but consider the fact that we might not want to add even
> more external dependencies on pginfra than we already have...

a) "send patches" is not the only way to improve the current state of 
affairs
b) I still haven't heard any technical reason, so no, I don't know what 
is holding this back or what the technical limitations are. I don't even 
know what needs to be patched and why.
c) Running on shared-infra of another legal entity sounds already like a 
privilege that either needs to be regulated or reverted. Being able to 
consume services that others can because of that is even more privileged 
and exclusive. I don't have anything against this, I know that things 
evolve how they evolve, and that's more than fine. But maybe its time to 
wake up and do things correctly. This email thread, if anything, I hope 
it serves as a call to do improve these things. And this is not only "on 
us, wanting to open community login to anyone".

>
>
>>      AFAIK:
>>
>> - PostgreSQL holds $142,000 on SPI of which less than $10,000 are
>> allocated for use
>> (https://wiki.postgresql.org/wiki/PgCon_2019_Developer_Meeting#09:35_-_09:40.09Funds_.26_Sponsors_update).
>>
>> - PostgreSQL EU had by 2018's years end more than $200,000 in cash
>> (https://www.postgresql.eu/about/ga/2019/financialreport/).
>> - PostgreSQL US has, as far as I know, half an order of magnitude more
>> cash than EU.
> aha

     "Aha" meaning?

>
>>      So... are we doing the right thing here, letting all this
>> infrastructure be run by unpaid volunteers? Don't get me wrong, I
>> applaud volunteers work and I love that some things are run by
>> volunteers (and most of them/you are good friends, thank you!). But
>> specially if the lack of extra hands *is holding progress back*, we're
>> doing a poor job by not using the resources that PostgreSQL has (and
>> more than I'm sure could be raised if needed) to move more things
>> *forward* and *faster*.
> so we are a few days into a discussion on enabling community auth for
> non-pginfra managed services (which has never been done before) and your
> analysis is already that we are "holding progress back"?

     I said that:

- There's something done potentially incorrectly (that some community 
members have privileged access to pg-infra and as well to services like 
community login)
- I propose it be corrected and expose to anyone what is exposed to a 
few privileged members of the very same Community
- All the Naysaying here is, yes, "holding progress back". Because there 
is no "sure, let's work together on this" but rather "no, to 
everything". Which is becoming a trend, lately....


> Again I
> consider that pretty offensive and demanding especially since there has
> not been shown any evidence (to me at least) that doing this would
> actually be "progress" and would allow things to move "forward"
> (whatever "forward" might mean in that case). _You_ are asking for
> something new and never done nor needed before - so implying it is
> somebody elses "fault" seems weird - to say the least.

     "Fault" is your term --definitely not mine.

     My apologies again if you felt offended. I won't insist more, I 
believe I have clarified my position very well: what you say it has 
never done before, it is done, and providing a service to one or more 
entities of the PostgreSQL Community and *not being provided* to any 
other entity in the PostgreSQL Community. I argue that should be changed 
in the spirit of fairness and have everyone be equal. And I believe it
is progress because it may make people in the Postgres Community that 
are not happy with the third-party authentication mechanisms of other 
companies, to use the trusted PostgreSQL Community login on other 
PostgreSQL-related services.


     Álvaro


>
>
>>
>>>
>>>          In summary: it is already opened to third parties, please help
>>>      us get to use it too, it's a very cool thing ;)
>>>
>>>
>>> In summary, it is open to third parties *running on our managed
>>> infrastructure*.  That is a huge difference.
>>      I understand the difference between running on the same managed
>> infrastructure or not. But I don't understand --because despite the
>> already lengthy thread nobody has stated what the reasons are-- why this
>> factor makes a difference. Is the auth server a web service? Where it
>> runs? What kind of authentication does it use that relies on the same
>> managed infrastructure? It uses SSL certificates emitted by a custom CA?
>> I can think of many things, please exemplify.
> Among others - It was never designed for this use case in mind, it has
> not been documented for this usecase and nobody has investigated any
> time (yet) in actually making this supportable and maintainable in the
> context of entirely third parties. Doing all this implies both on-time
> effort and ongoing long term effort (if we do this with completely
> external entities we also need to do long-term support of both the
> infrastructure and the code) and again, postgresql.org is not a general
> auth provider nor do we want to be one - so it is up to you to put
> forward a workable proposal (and no - claiming this would enable
> "progress" is not that).
>
>
>>>
>>>>        If there isn't such a policy, TBQH I don't think this is an
>>> example
>>>> of anything. And if there would be a policy, I believe that being a
>>>> Community Non-Profit and/or running a Community conference should
>>> not be
>>>> requisites for being able to use postgresql.org
>>> <http://postgresql.org> login. Why should they
>>>> be related at all? If anything, this is about providing *conveniency*
>>>> for PostgreSQL users to log into third party services without having to
>>>> depend on other third party authentication providers which whom those
>>>> users may feel less comfortable.
>>> Why should they *not* be related? Again, this is a service provided
>>> for free by volunteers. I'm pretty sure it's up to those volunteers to
>>> decide what to do with their time.
>>      Because there shouldn't be a difference whether this service, which
>> is already provided, is provided for a third party (that happens to run
>> on one location) or provided to another third party (that happens to run
>> on a possibly distinct location). Nobody is questioning volunteers work.
> it _is_ entirely different to run this service within pginfra or
> providing it to external entities - whether you believe that or not is
> up to you but it is a fact...
>
>
> [...]
>>      All in all: I wanted to provide PostgreSQL Community login because I
>> felt it was a good thing for the PostgreSQL Community. For us, it means
>> extra development effort where we have estimated that very few people,
>> if anyone, would use. Most people are happy with *either* (Google or
>> Twitter or GitHub or GitLab), which are the other auth providers we are
>> implementing. So the only reason we wanted to provide this is to bring
>> back here (as we do in many other areas) by "promoting" the use of the
>> PostgreSQL Community account, to create a broader sense of Community.
>> That services provided by the Community are available to the Community
>> through a Community authentication system, and not relying on external
>> providers like Google, given that we have one.
> well you have nnot stated the "broader community" argument before, and
> while I in fact see some merit in it - it is still a fact that the
> current service has not been designed with that goal in mind , neither
> from a code perspective nor is pginfra as team prepared for providing
> this kinda of service to entirely external entities from a management
> perspective.
>
>>      Now if this causes this reaction against it, and it's that
>> problematic, we will just simply forget about it and focus our efforts
>> in other areas. But it honestly leave a very bitter taste: there appears
>> to be some PostgreSQL Community services that are quite exclusive --in
>> the literal sense of exclusiveness; and not the inclusiveness I'd expect
>> from the PostgreSQL Community.
> Again - suggestions for code additions have been put forward, but as you
> say people have to focus their efforts - the focus of community auth as
> we have it now was not what you seem to want _now_.
>
>
>
>
> Stefan

On Sat, Sep 21, 2019 at 10:45 PM Álvaro Hernández <aht@ongres.com> wrote:

On 21/9/19 12:32, Stefan Kaltenbrunner wrote:
> On 9/20/19 3:14 AM, Álvaro Hernández wrote:
>>
>
> [...]
>
>>> Oh, and as a general rule, "requesting" unpaid volunteers to do work
>>> for you for free is in general not a great way to get them
>>> enthusiastic about helping out.
>>      Did I do so? I don't recall where or when I said that.
>>
>>      Irrespective of this: what you say I read as:
>>
>> - Either volunteers, due to being unpaid, are not doing their job
>> correctly (completely);
> tbh as one of those volunteers, I kinda find it pretty irritating that
> that the very first time somebody asks for community auth being opened
> to non-pginfra managed sites an association of "us" not doing our job
> correctly comes up just because that feature does not (and/or is not
> implemented in the way you want it) do like.

     TBQH, I'm having a really hard time to understand how this
conclusion could be derived from my words.

It's exactly what I've inferred from your emails, and clearly I'm not alone :-(

    In between this sentence you are replying to, and the next one, there was this one which you removed from your response:

"For the avoidance of doubt: Stefan, and any other pg-infra volunteer or anyone else how felt bad about my words: my deepest and most sincere apology. I never, under any circumstance, intended to do any negative statement about the job done or the team itself. I have a great deal of respect to any kind of volunteering in general, let alone for the one on helping on the technology that I love. I have volunteered tons of work on Postgres myself, and I cannot otherwise that feel in the same page. pg-infra: I know the work that you do and have done, and I really appreciate it, specially given how small team you are."

    The fact that you are still replying to the above sentence with the paragraph that follows removed, means that either:

* you didn't read it (in which case, please do);

* or you are acting in bad faith, by replying to the first sentence only, and deleting the following paragraph. You are insisting on the matter which is clearly responded on the second one, and showing a negative sentiment through the use of that smiley which IMHO should have turned into the opposite smiley after my apology and clarifications. The fact that you could be acting in bad faith, being a Core Member, really worries me.

   

 

     On the contrary: if anything, what I wanted to say is that why
pg-infra is unpaid and relying on volunteers to do the job, specially
when there are economic resources? Why don't we combine volunteer work
with paid jobs to maintain pg-infra *and help it do more things*? The
fact that there are enough economic resources (and more that could be
raised if needed), some of which remain unallocated year after year, if
anything, signals a failure in precisely allocating them to the best
possible uses. And one of them could be to augment the current pg-infra
team.

There are many reasons we're not doing that, not least of which are the matter of giving someone we probably don't know well keys to the castle

    Interesting. Many of us work on companies that provide services like "remote DBAs", where we are "given the keys to the castle" (in your definition) from third parties. Surprised that the same cannot apply to PG Infra. Are we so special? Don't you know how to do this legally, how to hire, trust people, specify boundaries, put mechanisms in place to ensure good access and faith? Are those implemented already with the current infra team, I suppose, despite trust and friendship, can't be extended to new ones? Would you trust me if I would volunteer? If so, what is the mechanism to trust new people into pg-infra? Maybe this is the reason pg-infra is understaffed, that there is no such mechanism in place. If so, I can help with it, I put mechanisms in place for even third parties (my company's customers) to trust us and give us "the keys to their castle" on their servers. And there are B$+ companies among them, with much more sensitive information than the PostgreSQL Community. You have all my help here.

    The fact that this wouldn't want to be done, and consequently hindering progress and improvement, would be a clear sign of mismanagement IMHO, given that there are obviously enough financial resources to accomplish it.

    If you cannot do this, however, the NPO Fundación PostgreSQL can volunteer to establish the legal, insurance and trust mechanisms to hire people to help manage infrastructure. Just let me know if you want us to do this.

and the fact that we're not setup in any way to employ or contract people and deal with the resulting management of them which also comes at a non-trivial cost, especially with a system such as pgInfra which has many moving parts.

 

- The infra belongs to (AFAIK) to the PostgreSQL Association of Canada
(CA).

That is entirely incorrect. PGCAC doesn't own any infrastructure at all.

The community infrastructure is owned mostly by the providers that kindly give us use of it, such as various contributing companies and hosting companies. We've only ever bought a couple of servers ourselves over the years, and that was through the SPI fund.

    This, if anything, make all the GDPR issues that I mentioned even more worrying...

    ... while not changing the substance of it: pg-infra is:

* Providing hosting services to entities like the PostgreSQL Europe Association.
* Providing login service to entities like the PostgreSQL Europe Association.
* Probably other services, and to other entities.
* Not willing to provide the above services to any other entity.

    This is creating a differentiation (through discrimination) and exclusiveness that nobody here is addressing but me. Don't you see it? I understand how things came this way, and I'm fine with this. But once this is identified, this needs to be resolved.

    It is not that I'm asking for community login to be opened up to third parties and this needs to be analyzed. For once, I already resigned from using the community login, and resign from doing something I believed would have helped the community. It is that this uncovered a very serious issue within the community that needs to be tackled. But nobody is tacking on this, rather being offended at every sentence I say.

    **Can you explain why some entities have those privileges above, and why others can't access to them?**

(and please don't answer with "because they run on pg-infra", because the question becomes then "why some entities can run on pg-infra and why can't others, or what are the policies to do so")

 

As an example, the PostgreSQL Europe Association (EU) runs on CA's
infra. Both are, from a legal perspective, different legal entities.
Other than the possibly legal (is there a services contract among them?)
and GDPR issues, which I just raised as a potential warning for
something that might be revisited, why EU is (or needs to be) different
from other entities in the PostgreSQL Community?

     I'd argue that specially the latter creates a privileged
differentiation. If the service cannot be open globally, it should be
open to no one. Since I won't obviously argue for this, I argue to work
together and find a way to open it to third parties and fix this -from a
legal perspective discriminating situation- asap.

Your argument is based on an incorrect premise.

    Your clarification doesn't change anything about the sentiment of the premise: it doesn't matter whether those resources are owned by CA or a third party: the issue at hand is what I commented above: that there are some services provided to some entities and not offered to anyone else. This is my argument. Remains unchanged (and, I insist, unanswered).

 

> If _you_ want such a service feel free to propose patches to enable it
> to be (suggestions on what needs to be done have been given on the
> thread already) but consider the fact that we might not want to add even
> more external dependencies on pginfra than we already have...

a) "send patches" is not the only way to improve the current state of
affairs

It's one of the things that is likely to be required to make this happen though. There's a fair amount of convincing needed,

    I believe this argument of "send patches if you want anything to change" is pretty limited in its vision. Because there are many other ways, many of which may be much more efficient to achieve the same result.

    Yet I have nothing against, but after 10 emails or so I'm still waiting on the same story: can anyone provide the technical details? There is still no answer here either...

though honestly I think you're doing a pretty good job of dissuading people from listening or wanting to help at the moment.

    I don't want people to have to do anything for me. I want the people who can make a decision to realize that there is an issue with the way pg-infra is providing services to some entities of the PostgreSQL Community that are not opened up to any other entity, and this is creating a discrimination. Since this needs to be fixed, the PostgreSQL Community would need to find the way of dealing with this. It's not me who needs to convince anyone. But I'm offering help, and proposing alternatives (besides the "*no* to all" that you and others have exhibited).

    That I'm dissuading people from listening,.. can you explain why? If I were misunderstood, I offered a very clear and detailed apology. That should have stopped any misunderstanding. Besides this, what am I doing, other than raising an important topic and bringing awareness, while offering thought and alternatives on this?

 

b) I still haven't heard any technical reason, so no, I don't know what
is holding this back or what the technical limitations are. I don't even
know what needs to be patched and why.

The main issue that I see at the moment is that the way Community Auth is written, authenticating through it will also share additional PII beyond the email address used to authenticate.

    Why? Can you elaborate? Is there any place where I can find this technical details, given that it is so hard to get any more detailed response on this email thread?

Obviously we could warn the user about that, but we also need to consider how and when that would be done, i.e. would we have a flag in the system for "external sites" that aren't run by pgInfra, which would trigger additional consent?

    I think this should not be needed and it's not the way other auth mechanism works. Besides this: I still see the distinction of a "external site" flawed. You are making a distinction between services and software run by privileged entities and the rest.

Or would we omit sending the extra info to external sites? Or maybe it would be better for us to just offer a SAML or oAuth service to external sites?

    oAuth should be the ideal mechanism, this is what I assumed it was and I was proposing from the beginning.

We would also need to consider how we deal with account deletion requests (or if we even need to).

    I don't see why (at least when using oAuth, and probably other mechanisms). I already commented this upthread.



    Álvaro

-- 

Alvaro Hernandez


-----------
OnGres

On 9/23/19 2:20 PM, Álvaro Hernández wrote:
> 
> 
> On 23/9/19 10:26, Dave Page wrote:
>>
>>
>> On Sat, Sep 21, 2019 at 10:45 PM Álvaro Hernández <aht@ongres.com 
>> <mailto:aht@ongres.com>> wrote:
>>
>>
>>
>>     On 21/9/19 12:32, Stefan Kaltenbrunner wrote:
>>     > On 9/20/19 3:14 AM, Álvaro Hernández wrote:
>>     >>
>>     >
>>     > [...]
>>     >
>>     >>> Oh, and as a general rule, "requesting" unpaid volunteers to
>>     do work
>>     >>> for you for free is in general not a great way to get them
>>     >>> enthusiastic about helping out.
>>     >>      Did I do so? I don't recall where or when I said that.
>>     >>
>>     >>      Irrespective of this: what you say I read as:
>>     >>
>>     >> - Either volunteers, due to being unpaid, are not doing their job
>>     >> correctly (completely);
>>     > tbh as one of those volunteers, I kinda find it pretty
>>     irritating that
>>     > that the very first time somebody asks for community auth being
>>     opened
>>     > to non-pginfra managed sites an association of "us" not doing
>>     our job
>>     > correctly comes up just because that feature does not (and/or is not
>>     > implemented in the way you want it) do like.
>>
>>          TBQH, I'm having a really hard time to understand how this
>>     conclusion could be derived from my words.
>>
>>
>> It's exactly what I've inferred from your emails, and clearly I'm not 
>> alone :-(
> 
>      In between this sentence you are replying to, and the next one, 
> there was this one which you removed from your response:
> 
> "For the avoidance of doubt: Stefan, and any other pg-infra volunteer or 
> anyone else how felt bad about my words: my deepest and most sincere 
> apology. I never, under any circumstance, intended to do any negative 
> statement about the job done or the team itself. I have a great deal of 
> respect to any kind of volunteering in general, let alone for the one on 
> helping on the technology that I love. I have volunteered tons of work 
> on Postgres myself, and I cannot otherwise that feel in the same page. 
> pg-infra: I know the work that you do and have done, and I really 
> appreciate it, specially given how small team you are."
> 
>      The fact that you are still replying to the above sentence with the 
> paragraph that follows removed, means that either:
> 
> * you didn't read it (in which case, please do);

have you ever considered that dave just wanted to express that he had 
similiar feelings to what I had - simply claiming he didn't read your 
apology seems like a weird interpretation...

> 
> * or you are acting in bad faith, by replying to the first sentence 
> only, and deleting the following paragraph. You are insisting on the 
> matter which is clearly responded on the second one, and showing a 
> negative sentiment through the use of that smiley which IMHO should have 
> turned into the opposite smiley after my apology and clarifications. The 
> fact that you could be acting in bad faith, being a Core Member, really 
> worries me.

but this seems like an even strangerinterpretation of how he quoted the 
email and what he said...

> 
> 
> 
>>          On the contrary: if anything, what I wanted to say is that why
>>     pg-infra is unpaid and relying on volunteers to do the job, specially
>>     when there are economic resources? Why don't we combine volunteer
>>     work
>>     with paid jobs to maintain pg-infra *and help it do more things*? The
>>     fact that there are enough economic resources (and more that could be
>>     raised if needed), some of which remain unallocated year after
>>     year, if
>>     anything, signals a failure in precisely allocating them to the best
>>     possible uses. And one of them could be to augment the current
>>     pg-infra
>>     team.
>>
>>
>> There are many reasons we're not doing that, not least of which are 
>> the matter of giving someone we probably don't know well keys to the 
>> castle
> 
>      Interesting. Many of us work on companies that provide services 
> like "remote DBAs", where we are "given the keys to the castle" (in your 
> definition) from third parties. Surprised that the same cannot apply to 
> PG Infra. Are we so special? Don't you know how to do this legally, how 
> to hire, trust people, specify boundaries, put mechanisms in place to 
> ensure good access and faith? Are those implemented already with the 
> current infra team, I suppose, despite trust and friendship, can't be 
> extended to new ones? Would you trust me if I would volunteer? If so, 
> what is the mechanism to trust new people into pg-infra? Maybe this is 
> the reason pg-infra is understaffed, that there is no such mechanism in 
> place. If so, I can help with it, I put mechanisms in place for even 
> third parties (my company's customers) to trust us and give us "the keys 
> to their castle" on their servers. And there are B$+ companies among 
> them, with much more sensitive information than the PostgreSQL 
> Community. You have all my help here.

there might be some valid points in here that we could discuss in 
different discussion but I don't really think they are a good fit for 
this thread.

> 
>      The fact that this wouldn't want to be done, and consequently 
> hindering progress and improvement, would be a clear sign of 
> mismanagement IMHO, given that there are obviously enough financial 
> resources to accomplish it.

again - this implies that there is actual progress and improvment that 
is "hindered" (and even more so you maybe actual mismanagement) as well 
as the fact that simply throwing money at it would magically solve it. 
As far as my interpretation of the current discussion goes we are 
talking about a new service for a few days that has never been done 
before, where there is clearly not even a conclusion on whether that is 
actuall wanted, needed or actual within the scope of the relevant parties.



> 
>      If you cannot do this, however, the NPO Fundación PostgreSQL can 
> volunteer to establish the legal, insurance and trust mechanisms to hire 
> people to help manage infrastructure. Just let me know if you want us to 
> do this.

you keep moving the target here - there is a "lot" of stuff that is 
involved her, that is the actual physical OS/infrastructure, the code of 
multiple different software projects(pgweb, pginfra, pgeu,...) with 
100k+ LoC and developed over 10+ years as well as organisational and 
operational challenges but they way you are arguing in this thread makes 
me not really motivated to make a more detailed list...



> 
> 
>> and the fact that we're not setup in any way to employ or contract 
>> people and deal with the resulting management of them which also comes 
>> at a non-trivial cost, especially with a system such as pgInfra which 
>> has many moving parts.
>>
>>     - The infra belongs to (AFAIK) to the PostgreSQL Association of
>>     Canada
>>     (CA). 
>>
>>
>> That is entirely incorrect. PGCAC doesn't own any infrastructure at all.
>>
>> The community infrastructure is owned mostly by the providers that 
>> kindly give us use of it, such as various contributing companies and 
>> hosting companies. We've only ever bought a couple of servers 
>> ourselves over the years, and that was through the SPI fund.
> 
>      This, if anything, make all the GDPR issues that I mentioned even 
> more worrying...
> 
>      ... while not changing the substance of it: pg-infra is:
> 
> * Providing hosting services to entities like the PostgreSQL Europe 
> Association.
> * Providing login service to entities like the PostgreSQL Europe 
> Association.
> * Probably other services, and to other entities.
> * Not willing to provide the above services to any other entity.
> 
>      This is creating a differentiation (through discrimination) and 
> exclusiveness that nobody here is addressing but me. Don't you see it? I 
> understand how things came this way, and I'm fine with this. But once
> this is identified, this needs to be resolved.

well you keep arguing this in the direction of discimination but (seem) 
to ignore the other aspects that have been mentioned - like the fact 
that we are trying to strongly consider on a technical level "what is on 
our infrastructure, what is our responsibility and goal and what are 
services we do not want, cannot or are simply not sensible to be 
provided by us".
Like:

* "we are not a general hosting provider" - we have tried and done that 
before and it was a desaster

* "we are not a generic software and scm hosting platform" - done that 
(gborg, pgfoundry, git hosting, media hosting, developer websites 
hosting) and it was a long term technical debt that took enormous 
amounts of resources to get rid off (and we are still finding remains of 
that)

and (imho) we are _also_ not a general login service provider

Also - as a personal comment, Money is always easy to find for doing a 
nice on-time funding of a neat feature or bullpoint thingy, it is much 
harder to get reliable multi-year commitment for stuff that wont show up 
in press release or involves thankless tasks like "deprovisioning" or 
cleanup of old mistakes or experiments that failed.


> 
>      It is not that I'm asking for community login to be opened up to 
> third parties and this needs to be analyzed. For once, I already 
> resigned from using the community login, and resign from doing something 
> I believed would have helped the community. It is that this uncovered a 
> very serious issue within the community that needs to be tackled. But 
> nobody is tacking on this, rather being offended at every sentence I say.

so what are you actually asking for now - and no I don't agree we found 
a serious community issue here. Maybe there is ground for cleaer 
policies in some aspects but that can be asked for and discussed in a 
different way...


> 
>      **Can you explain why some entities have those privileges above, 
> and why others can't access to them?**
> 
> (and please don't answer with "because they run on pg-infra", because 
> the question becomes then "why some entities can run on pg-infra and why 
> can't others, or what are the policies to do so")

well - the answer is indeed "because they run of pginfra" whether you 
like it or not. Running on pginfra currently is a matter of asking the 
team and taking a decision within the team - and we are actively 
providing new services on pginfra for others. We indeed have rejected 
services to run on pginfra in the past but it's not like we are getting 
asked once a week or so - for your particular request I'm not aware of 
any inquiry to that regard...


> 
>>     As an example, the PostgreSQL Europe Association (EU) runs on CA's
>>     infra. Both are, from a legal perspective, different legal entities.
>>     Other than the possibly legal (is there a services contract among
>>     them?)
>>     and GDPR issues, which I just raised as a potential warning for
>>     something that might be revisited, why EU is (or needs to be)
>>     different
>>     from other entities in the PostgreSQL Community?
>>
>>          I'd argue that specially the latter creates a privileged
>>     differentiation. If the service cannot be open globally, it should be
>>     open to no one. Since I won't obviously argue for this, I argue to
>>     work
>>     together and find a way to open it to third parties and fix this
>>     -from a
>>     legal perspective discriminating situation- asap.
>>
>>
>> Your argument is based on an incorrect premise.
> 
>      Your clarification doesn't change anything about the sentiment of 
> the premise: it doesn't matter whether those resources are owned by CA 
> or a third party: the issue at hand is what I commented above: that 
> there are some services provided to some entities and not offered to 
> anyone else. This is my argument. Remains unchanged (and, I insist, 
> unanswered).

see above - just the fact that you don't like the answer does not mean 
it was not given...

> 
>>     > If _you_ want such a service feel free to propose patches to
>>     enable it
>>     > to be (suggestions on what needs to be done have been given on the
>>     > thread already) but consider the fact that we might not want to
>>     add even
>>     > more external dependencies on pginfra than we already have...
>>
>>     a) "send patches" is not the only way to improve the current state of
>>     affairs
>>
>>
>> It's one of the things that is likely to be required to make this 
>> happen though. There's a fair amount of convincing needed,
> 
>      I believe this argument of "send patches if you want anything to 
> change" is pretty limited in its vision. Because there are many other 
> ways, many of which may be much more efficient to achieve the same result.

in this case please present those ways
  or stop arguing in that direction.

> 
>      Yet I have nothing against, but after 10 emails or so I'm still 
> waiting on the same story: can anyone provide the technical details? 
> There is still no answer here either...

considered the fact that people might expect you to look at the code and 
come up with an analysis and proposal instead of demanding that we do it 
for you? This is similiar to proposing something for the core database 
code and comes across as 'I want a Multithreaded Postmaster("external 
authentication service") now because others do it as well (Microsoft, 
MySQL, Oracle") and I dont see any technical problems so just do it now' 
and a response like "uhm oh it is not that easy" gets your reply as 
"tell me every single technical issue or there is no issue"

> 
> 
>> though honestly I think you're doing a pretty good job of dissuading 
>> people from listening or wanting to help at the moment.
> 
>      I don't want people to have to do anything for me. I want the 
> people who can make a decision to realize that there is an issue with 
> the way pg-infra is providing services to some entities of the 
> PostgreSQL Community that are not opened up to any other entity, and 
> this is creating a discrimination. Since this needs to be fixed, the 
> PostgreSQL Community would need to find the way of dealing with this. 
> It's not me who needs to convince anyone. But I'm offering help, and 
> proposing alternatives (besides the "*no* to all" that you and others 
> have exhibited).

Again - there is still the fundamental misunderstanding that "something 
needs to be fixed", and I not sure what "alternatives" you are talking 
about that have been proposed?

> 
>      That I'm dissuading people from listening,.. can you explain why? 
> If I were misunderstood, I offered a very clear and detailed apology. 
> That should have stopped any misunderstanding. Besides this, what am I 
> doing, other than raising an important topic and bringing awareness, 
> while offering thought and alternatives on this?
> 
> 
>>     b) I still haven't heard any technical reason, so no, I don't know
>>     what
>>     is holding this back or what the technical limitations are. I
>>     don't even
>>     know what needs to be patched and why.
>>
>>
>> The main issue that I see at the moment is that the way Community Auth 
>> is written, authenticating through it will also share additional PII 
>> beyond the email address used to authenticate.
> 
>      Why? Can you elaborate? Is there any place where I can find this 
> technical details, given that it is so hard to get any more detailed 
> response on this email thread?

see above

> 
>> Obviously we could warn the user about that, but we also need to 
>> consider how and when that would be done, i.e. would we have a flag in 
>> the system for "external sites" that aren't run by pgInfra, which 
>> would trigger additional consent?
> 
>      I think this should not be needed and it's not the way other auth 
> mechanism works. Besides this: I still see the distinction of a 
> "external site" flawed. You are making a distinction between services
> and software run by privileged entities and the rest.

well _you_ consider it "flawed" - for us it has been a very sucessful 
operational model in the last decade that provided a (imho - others can 
disagree) very reliable, modern and well managed environment for the 
project as a whole.


> 
> 
>> Or would we omit sending the extra info to external sites? Or maybe it 
>> would be better for us to just offer a SAML or oAuth service to 
>> external sites?
> 
>      oAuth should be the ideal mechanism, this is what I assumed it was 
> and I was proposing from the beginning.
> 
>>
>> We would also need to consider how we deal with account deletion 
>> requests (or if we even need to).
> 
>      I don't see why (at least when using oAuth, and probably other 
> mechanisms). I already commented this upthread.

it is not oAuth (though not very far from it implementation wise) - 
which already shows that this entire service was _NOT_ designed or 
considered for the usecase you originally asked for, but you could have 
figured that our on your own in a few minutes as well...




Stefan

On Mon, Sep 23, 2019 at 1:20 PM Álvaro Hernández <aht@ongres.com> wrote:

     TBQH, I'm having a really hard time to understand how this
conclusion could be derived from my words.

It's exactly what I've inferred from your emails, and clearly I'm not alone :-(

    In between this sentence you are replying to, and the next one, there was this one which you removed from your response:

"For the avoidance of doubt: Stefan, and any other pg-infra volunteer or anyone else how felt bad about my words: my deepest and most sincere apology. I never, under any circumstance, intended to do any negative statement about the job done or the team itself. I have a great deal of respect to any kind of volunteering in general, let alone for the one on helping on the technology that I love. I have volunteered tons of work on Postgres myself, and I cannot otherwise that feel in the same page. pg-infra: I know the work that you do and have done, and I really appreciate it, specially given how small team you are."

    The fact that you are still replying to the above sentence with the paragraph that follows removed, means that either:

* you didn't read it (in which case, please do);

* or you are acting in bad faith, by replying to the first sentence only, and deleting the following paragraph. You are insisting on the matter which is clearly responded on the second one, and showing a negative sentiment through the use of that smiley which IMHO should have turned into the opposite smiley after my apology and clarifications. The fact that you could be acting in bad faith, being a Core Member, really worries me.

I was responding to the specific point that you're "having a really hard time to understand how this conclusion could be derived from my words". Whether or not you later apologised is irrelevant to the comment that I read your words in the same way as Stefan.

That neither means that I didn't read it (I did) or that I was acting in bad faith (I was not).

    I believe you have an important position as a Core Member. As such, IMHO you should try to avoid confrontation and favor understanding among the parties.

    If I said something that was understood wrongly, and I later clarified it and make it very clear that it was the *opposite* of my intentions and apologized for it, the fact that you ignored (explicitly removed) the apology and instead go back to a topic that was already closed (a misunderstanding) does not contribute to easy things but rather seems to be poking in the eye. Something I believe it is inappropriate of someone in your position.

     If you say it was not bad faith, I take your word and I won't come back to this. Thank you.


    Álvaro

-- 

Alvaro Hernandez


-----------
OnGres

This thread is mostly going around in circles. I don't foresee anything productive coming out of it TBH, but I've cut it down to a few points I'd like to still make.

And yes, I have cut severely in the amount of text, and am responding to three mails at once. Because I see no point in re-iterating the answers that have already been said.

On Fri, Sep 20, 2019 at 3:14 AM Álvaro Hernández <aht@ongres.com> wrote:

On 19/9/19 13:53, Magnus Hagander wrote:

On Wed, Sep 18, 2019 at 5:16 PM Álvaro Hernández <aht@ongres.com> wrote:

On 18/9/19 3:45, Magnus Hagander wrote:

    But back on topic, on what concerns my request: let's open this up to any third party organisation --it has already been done. I don't see why having "the team the ability to manage all the data" changes anything. What I'm requesting access to is a system for third-party authentication, similar to "login with Google" or any other auth provider. There's no "forced account delete" mechanism that I'm aware of, and there is little to no information sharing other than "hey, please authenticate this person and let me know the boolean information of whether that was successful or not" (optionally request name and email, as other authentication providers do, that is PII, but that's it). What auth providers do is a way to force delete a session (an authentication token, which typically expires quickly, but could be forcibly expired). This is optional, and in no way would force any deletion on the third party (it is the user who should use the third party's account deletion procedures).

Just because Google does something one way, doesn't mean that we want to do it that way. We are allowed to treat our users better than Google treat their tracking-victims for example, and would like to 

stick to that level.

    I used Google as an example. You came back with an unrelated, Google rant (????).

You are correct, my apologies. That was terrible phraising.

    Thank you.

So what I meant to highlight was: you use Google as an example of a free authentication provider. That is not correct -- you pay to use google authentication by feeding google tracking data about your users. The same goes for any of the other examples of other authentication providers mentioned. It is not wrong to label them authentication providers, but it *is* wrong in this context to label them as free.

    Precisely because I know there is people that think like you --I don't completely agree with you here, but this is irrelevant-- that I want to provide users of PostgreSQL services with PostgreSQL Community authentication. Because that's something they may trust more than these third party providers. But apparently nobody wants to change anything, so PostgreSQL users are left with only these options that you don't like.

Oh, and as a general rule, "requesting" unpaid volunteers to do work for you for free is in general not a great way to get them enthusiastic about helping out.

    Did I do so? I don't recall where or when I said that.

Your own words, in the text above:
". What I'm requesting access to is a system for third-party authentication, similar to "login with Google" or any other auth provider."

How is that not "requesting", when you use that very word?

    It is, of course. But I am no one to tell pg-infra team what or when they should do things, and I haven't done that. For now I'm asking for thoughts, and possibly help, but all doors have been closed.

    Rather, I said that if there are not enough volunteers or they are not paid, given that we have enough resources, they should get paid and/or create jobs to fulfill these jobs (not only (or not even) for authentication, but many others).

> >> - Either volunteers, due to being unpaid, are not doing their job
> >> correctly (completely);
> > tbh as one of those volunteers, I kinda find it pretty irritating that
> > that the very first time somebody asks for community auth being opened
> > to non-pginfra managed sites an association of "us" not doing our job
> > correctly comes up just because that feature does not (and/or is not
> > implemented in the way you want it) do like.

>      TBQH, I'm having a really hard time to understand how this
> conclusion could be derived from my words. But it doesn't matter, it's 
> my bad anyway if I made you, or anyone else, feel this way.

So you write "Either volunteers, due to being unpaid, are not doing their job correctly (completely);" 

-- but we're not supposed to read that as the volunteers not doing their job?

    Did you read my apology? I used a wrong language, maybe due to not being a native English speaker, or whatever reason, but what you are all understanding is not what I meant. I wrote a lengthy paragraph explaining what I really wanted to say and apologizing for the confusion.

    Why are you cherry-picking again, back in history, on this topic? I made my point very clear already. If you need me to apologize again for what I didn't mean to mean, I will do happily. But I expected that would be enough clarification of the misunderstanding.

    PostgreSQL *has* financial resources that remain unused, and there's lack of hands. Let's put these resources, mostly coming to donations, to good use!

Is there anything you write that actually means what it says? Because it's really hard to understand what you mean if you write them using words that mean other things.

This is the second time it's literally in the very text you quote and then deny having said.

    That's your opinion, I can only respect it, but disagree with it. Besides, I don't think this comment is constructive.

> * you didn't read it (in which case, please do);

You should maybe try that yourself? At least read the  parts that you wrote yourself?

    What haven't I read? I said that because I offered and apology and Dave removed it and responded to the part that was *fixed* by the apology.

> * or you are acting in bad faith, by replying to the first sentence only, and deleting the following paragraph. 

Yes, I did cut intentionally in this email, just like Dave did. I don't know why he did it, but it should be clear why I did it.

    It's not a problem cutting parts of an email. It is a problem to cut an apology and respond to the phrase above it, as it removes all the following context, when the apology refers to that phrase, and actually and completely changes its meaning.

So you are basically repeatedly accusing the pginfra volunteers of not doing a proper job.

    This is an statement which I cannot tolerate. It is unacceptable that you say this after my apology. I beg you to correct this statement, this is inappropriate and unacceptable coming from a Core Member.

Then you are accusing a core team member of acting in  bad faith.

    And I believe that you accusing me again of accusing the pginfra volunteers is also bad faith.

    I cannot understand all this backslash against. I offered a very honest and sincere apology over some words which I believe were misunderstood.

    I will say it again, even though I don't understand why it is necessary:

*To all pg-infra volunteers, and all volunteers of the PostgreSQL Community (considering myself also included): I really appreciate all your work. All the work that you have done in the past, all the work being done in the present, and even the work that will be done in the future. Your work is invaluable. I am fully committed to support and help as much as possible. The PostgreSQL software, all of its ecosystem, and all the community around are simply amazing.* Plus, I have no authority to request anyone to do any work. If I have said that some work needs to be done, it is just my opinion on what I believe could be a good thing to do. Please do not look any further than this.

    Now, if there are not enough hands, and there are financial resources, I propose, again, to use them for the best uses possible. That may include helping the pg-infra team if necessary.

So yeah, I think it's time to close this thread out.

>   I believe this argument of "send patches if you want anything to change" is pretty limited in its vision. Because there are many other ways, many of which may be much more efficient to achieve the same result.

It might be limiting. But it's how the entire PostgreSQL project has worked through all time. If you want something done, you either do it yourself or you convince somebody else to do it.

    When something "has always worked like this", it doesn't mean it is still the best way to do it. I'm only saying there are more ways, and I propose to evaluate them. But ears closed, nothing wants to be changed or even considered. Let's just keep everything as it is, no progress, no improvement, not even (constructive) discussion.

And accusing others of not doing their job has never been a way to accomplish that.

    Please refer to my words above and my, again, clarification. You are taking this way too far.

   

>    Why? Can you elaborate? Is there any place where I can find this technical details, given that it is so hard to get any more detailed response on this email thread?

In the very first response on this thread, Jonathan sent you the link to the documentation *and source code* for the system. If that's not technical enough, then what you actually want? I can send you a precompiled bytecode file?

    Maybe a summary, context, a 2 or 5 or 10 bullets explaining what needs to be changed?

    Surely I can dig the source code, but maybe that 10 minute effort (you all already spent way more time on this thread) would save hours. I don't think it's something so huge to ask for.

>   ... while not changing the substance of it: pg-infra is:

> * Providing hosting services to entities like the PostgreSQL Europe Association.
> * Providing login service to entities like the PostgreSQL Europe Association.
> * Probably other services, and to other entities.
> * Not willing to provide the above services to any other entity.
>     This is creating a differentiation (through discrimination) and exclusiveness that nobody here is addressing but me. Don't you see it? I understand how things came this way, and I'm fine with this. But once this is identified, this needs to be resolved.

Except you have explicitly *rejected* the offer of being hosted on pginfra. It was offered, and you said no. Surely that is not *our* fault.

There is nothing preventing you from hosting your service on pginfra under the same terms as anybody else. But you didn't *want* that.

    Can you please share what are those terms? Are they public? Are they open to anyone? Can really any entity host any service within pginfra? Please let me know, I'm very interested indeed. Thank you.

In summary:

You wrote:

>    postgresqlco.nf is a free service, developed and run by OnGres. I don't think is a good fit to run on a non-profit entity's infrastructure. Is PostgreSQL infra providing hosting services for companies?

And you are absolutely correct. PostgreSQL infra is not providing hosting services for companies.

So why should we build and maintain an authentication service for companies?

    What I want is a fair ecosystem and an inclusive Community. There are at least two services (surely more) that are provided, so far, to only some entities: infrastructure and postgresql.org login. *If* they are provided to some, I truly believe they should be provided to the whole Community, regardless of whether they are NPOs or companies or whomever, under the same terms. That is an inclusive Community, that's an Open Community.

    Regardless of this: I believe the postgresql.org login is something that may benefit the Community as a whole, and the more they use it (whatever kind of entity it would be) it would be a good thing. This is all that I wanted to accomplish here.

This thread is clearly not getting anywhere. Let's close it here.

I would suggest you proceed down one of two paths:

1. Provide an actual complete proposal *including the code to implement it*, which also outlines the requirements to support the system long-term, for something based on the current community authentication. This has repeatedly been requested. You don't like this option, so that's fine.

2. Build out a working authentication service that solves this problem, under a different umbrella. Once you have a proven solution for it, you will have a much easier time convincing people of using it, instead of just requesting other people to the work. I would *love* for pginfra not to have to have to deal with the user service parts of handling it for example. Anything that solves that part would be *much* appreciated, and it would be an actual *improvement* over what is there today.

    I'm OK closing the thread here. I believe the path should be different, though: the PostgreSQL Community (I guess, Core) should decide on what services are provided to the Community and rule out (if they aren't) under which terms they are provided. Leaning on the "the more open, the better" side, IMHO, and without creating privileged positions.


    Regards,

    Álvaro

-- 

Alvaro Hernandez


-----------
OnGres

On 23/9/19 9:28, Stefan Kaltenbrunner wrote:
> On 9/23/19 2:20 PM, Álvaro Hernández wrote:
>>
>>
>> On 23/9/19 10:26, Dave Page wrote:
>>>
>>>
>>> On Sat, Sep 21, 2019 at 10:45 PM Álvaro Hernández <aht@ongres.com 
>>> <mailto:aht@ongres.com>> wrote:
>>>
>>>
>>>
>>>     On 21/9/19 12:32, Stefan Kaltenbrunner wrote:
>>>     > On 9/20/19 3:14 AM, Álvaro Hernández wrote:
>>>     >>
>>>     >
>>>     > [...]
>>>     >
>>>     >>> Oh, and as a general rule, "requesting" unpaid volunteers to
>>>     do work
>>>     >>> for you for free is in general not a great way to get them
>>>     >>> enthusiastic about helping out.
>>>     >>      Did I do so? I don't recall where or when I said that.
>>>     >>
>>>     >>      Irrespective of this: what you say I read as:
>>>     >>
>>>     >> - Either volunteers, due to being unpaid, are not doing their 
>>> job
>>>     >> correctly (completely);
>>>     > tbh as one of those volunteers, I kinda find it pretty
>>>     irritating that
>>>     > that the very first time somebody asks for community auth being
>>>     opened
>>>     > to non-pginfra managed sites an association of "us" not doing
>>>     our job
>>>     > correctly comes up just because that feature does not (and/or 
>>> is not
>>>     > implemented in the way you want it) do like.
>>>
>>>          TBQH, I'm having a really hard time to understand how this
>>>     conclusion could be derived from my words.
>>>
>>>
>>> It's exactly what I've inferred from your emails, and clearly I'm 
>>> not alone :-(
>>
>>      In between this sentence you are replying to, and the next one, 
>> there was this one which you removed from your response:
>>
>> "For the avoidance of doubt: Stefan, and any other pg-infra volunteer 
>> or anyone else how felt bad about my words: my deepest and most 
>> sincere apology. I never, under any circumstance, intended to do any 
>> negative statement about the job done or the team itself. I have a 
>> great deal of respect to any kind of volunteering in general, let 
>> alone for the one on helping on the technology that I love. I have 
>> volunteered tons of work on Postgres myself, and I cannot otherwise 
>> that feel in the same page. pg-infra: I know the work that you do and 
>> have done, and I really appreciate it, specially given how small team 
>> you are."
>>
>>      The fact that you are still replying to the above sentence with 
>> the paragraph that follows removed, means that either:
>>
>> * you didn't read it (in which case, please do);
>
> have you ever considered that dave just wanted to express that he had 
> similiar feelings to what I had - simply claiming he didn't read your 
> apology seems like a weird interpretation...

     Have you ever considered accepting, or even thanking, my apologies?

     Or at least, tell me if they are not enough for you.


     Best,

     Álvaro

-- 

Alvaro Hernandez


-----------
OnGres

On 23/9/19 9:28, Stefan Kaltenbrunner wrote:
>
>>>
>>>
>>> There are many reasons we're not doing that, not least of which are 
>>> the matter of giving someone we probably don't know well keys to the 
>>> castle
>>
>>      Interesting. Many of us work on companies that provide services 
>> like "remote DBAs", where we are "given the keys to the castle" (in 
>> your definition) from third parties. Surprised that the same cannot 
>> apply to PG Infra. Are we so special? Don't you know how to do this 
>> legally, how to hire, trust people, specify boundaries, put 
>> mechanisms in place to ensure good access and faith? Are those 
>> implemented already with the current infra team, I suppose, despite 
>> trust and friendship, can't be extended to new ones? Would you trust 
>> me if I would volunteer? If so, what is the mechanism to trust new 
>> people into pg-infra? Maybe this is the reason pg-infra is 
>> understaffed, that there is no such mechanism in place. If so, I can 
>> help with it, I put mechanisms in place for even third parties (my 
>> company's customers) to trust us and give us "the keys to their 
>> castle" on their servers. And there are B$+ companies among them, 
>> with much more sensitive information than the PostgreSQL Community. 
>> You have all my help here.
>
> there might be some valid points in here that we could discuss in 
> different discussion but I don't really think they are a good fit for 
> this thread.

     I agree. Happy to participate on those and EOF this thread. Thank 
you for this, it is the very first positive answer to anything that I 
have said so far.



>
>>
>>      The fact that this wouldn't want to be done, and consequently 
>> hindering progress and improvement, would be a clear sign of 
>> mismanagement IMHO, given that there are obviously enough financial 
>> resources to accomplish it.
>
> again - this implies that there is actual progress and improvment that 
> is "hindered" (and even more so you maybe actual mismanagement) as 
> well as the fact that simply throwing money at it would magically 
> solve it. 

     No, but well done it could. Worse case, it would help. Not doing 
anything, surely won't help. Keeping donations in the bank is not a wise 
use of those donations either.


> As far as my interpretation of the current discussion goes we are 
> talking about a new service for a few days that has never been done 
> before, where there is clearly not even a conclusion on whether that 
> is actuall wanted, needed or actual within the scope of the relevant 
> parties.
>
>
>
>>
>>      If you cannot do this, however, the NPO Fundación PostgreSQL can 
>> volunteer to establish the legal, insurance and trust mechanisms to 
>> hire people to help manage infrastructure. Just let me know if you 
>> want us to do this.
>
> you keep moving the target here - there is a "lot" of stuff that is 
> involved her, that is the actual physical OS/infrastructure, the code 
> of multiple different software projects(pgweb, pginfra, pgeu,...) with 
> 100k+ LoC and developed over 10+ years as well as organisational and 
> operational challenges but they way you are arguing in this thread 
> makes me not really motivated to make a more detailed list...

     We work with customers much larger than that, with way more 
infrastructure, with much more sensitive PII data and extremely valuable 
assets that need to be protected with very strict means. Yet we help 
them run their PostgreSQL servers. We know how to do this from a legal 
and management and technical perspective, and I can only insist on 
offering my help here.

>
>
>
>>
>>
>>> and the fact that we're not setup in any way to employ or contract 
>>> people and deal with the resulting management of them which also 
>>> comes at a non-trivial cost, especially with a system such as 
>>> pgInfra which has many moving parts.
>>>
>>>     - The infra belongs to (AFAIK) to the PostgreSQL Association of
>>>     Canada
>>>     (CA).
>>>
>>> That is entirely incorrect. PGCAC doesn't own any infrastructure at 
>>> all.
>>>
>>> The community infrastructure is owned mostly by the providers that 
>>> kindly give us use of it, such as various contributing companies and 
>>> hosting companies. We've only ever bought a couple of servers 
>>> ourselves over the years, and that was through the SPI fund.
>>
>>      This, if anything, make all the GDPR issues that I mentioned 
>> even more worrying...
>>
>>      ... while not changing the substance of it: pg-infra is:
>>
>> * Providing hosting services to entities like the PostgreSQL Europe 
>> Association.
>> * Providing login service to entities like the PostgreSQL Europe 
>> Association.
>> * Probably other services, and to other entities.
>> * Not willing to provide the above services to any other entity.
>>
>>      This is creating a differentiation (through discrimination) and 
>> exclusiveness that nobody here is addressing but me. Don't you see 
>> it? I understand how things came this way, and I'm fine with this. 
>> But once this is identified, this needs to be resolved.
>
> well you keep arguing this in the direction of discimination but 
> (seem) to ignore the other aspects that have been mentioned - like the 
> fact that we are trying to strongly consider on a technical level 
> "what is on our infrastructure, what is our responsibility and goal 
> and what are services we do not want, cannot or are simply not 
> sensible to be provided by us".
> Like:
>
> * "we are not a general hosting provider" - we have tried and done 
> that before and it was a desaster
>
> * "we are not a generic software and scm hosting platform" - done that 
> (gborg, pgfoundry, git hosting, media hosting, developer websites 
> hosting) and it was a long term technical debt that took enormous 
> amounts of resources to get rid off (and we are still finding remains 
> of that)
>
> and (imho) we are _also_ not a general login service provider

     What I'm saying is that there are several entities here that are 
"conflated": PostgreSQL Association of Canada, which holds the 
trademarks and AFAIK the "accepted legal estatutes" of the Community; 
and then there is other entities like EU or US that are separate legal 
entities, no different from any other entities in the PostgreSQL 
Community (say Fundación PostgreSQL or any local user group, for that 
matter). And then, there should be a separation of the 
benefits/services/etc that "members" enjoy, and they should be open to 
all under the same terms. Limited to NPOs or not. But as of today they 
aren't, and some entities are "special". I get it, it's OK they are, but 
they shouldn't be in the future. Every Community Member should have 
equal opportunities.

>
> Also - as a personal comment, Money is always easy to find for doing a 
> nice on-time funding of a neat feature or bullpoint thingy, it is much 
> harder to get reliable multi-year commitment for stuff that wont show 
> up in press release or involves thankless tasks like "deprovisioning" 
> or cleanup of old mistakes or experiments that failed.

     I'm willing to help on multi-year commitments. Plus any help, even 
if temporary, is better than none.

>
>
>>
>>      It is not that I'm asking for community login to be opened up to 
>> third parties and this needs to be analyzed. For once, I already 
>> resigned from using the community login, and resign from doing 
>> something I believed would have helped the community. It is that this 
>> uncovered a very serious issue within the community that needs to be 
>> tackled. But nobody is tacking on this, rather being offended at 
>> every sentence I say.
>
> so what are you actually asking for now - and no I don't agree we 
> found a serious community issue here. Maybe there is ground for cleaer 
> policies in some aspects but that can be asked for and discussed in a 
> different way...

     To provide a clear separation between PostgreSQL Community entities
and provide equal opportunities.

>
>
>>
>>      **Can you explain why some entities have those privileges above, 
>> and why others can't access to them?**
>>
>> (and please don't answer with "because they run on pg-infra", because 
>> the question becomes then "why some entities can run on pg-infra and 
>> why can't others, or what are the policies to do so")
>
> well - the answer is indeed "because they run of pginfra" whether you 
> like it or not. Running on pginfra currently is a matter of asking the 
> team and taking a decision within the team - and we are actively 
> providing new services on pginfra for others. We indeed have rejected 
> services to run on pginfra in the past but it's not like we are 
> getting asked once a week or so - for your particular request I'm not 
> aware of any inquiry to that regard...

     I don't have anything about anybody running on pginfra. What I'm 
saying is what the rules are for that, is this open equally to any 
member? And if so: I believe postgresql.org is a service that would 
benefit the Community as a whole, and as such I advocate for it to be 
open to the ones not hosted on pg-infra, and I have repeatedly asked for 
what are the technical reasons of why this is hard (other than "go to 
the repo and look for yourself").

>
>
>>
>>>     As an example, the PostgreSQL Europe Association (EU) runs on CA's
>>>     infra. Both are, from a legal perspective, different legal 
>>> entities.
>>>     Other than the possibly legal (is there a services contract among
>>>     them?)
>>>     and GDPR issues, which I just raised as a potential warning for
>>>     something that might be revisited, why EU is (or needs to be)
>>>     different
>>>     from other entities in the PostgreSQL Community?
>>>
>>>          I'd argue that specially the latter creates a privileged
>>>     differentiation. If the service cannot be open globally, it 
>>> should be
>>>     open to no one. Since I won't obviously argue for this, I argue to
>>>     work
>>>     together and find a way to open it to third parties and fix this
>>>     -from a
>>>     legal perspective discriminating situation- asap.
>>>
>>>
>>> Your argument is based on an incorrect premise.
>>
>>      Your clarification doesn't change anything about the sentiment 
>> of the premise: it doesn't matter whether those resources are owned 
>> by CA or a third party: the issue at hand is what I commented above: 
>> that there are some services provided to some entities and not 
>> offered to anyone else. This is my argument. Remains unchanged (and, 
>> I insist, unanswered).
>
> see above - just the fact that you don't like the answer does not mean 
> it was not given...

     I believe it was not addressed.

>
>>
>>>     > If _you_ want such a service feel free to propose patches to
>>>     enable it
>>>     > to be (suggestions on what needs to be done have been given on 
>>> the
>>>     > thread already) but consider the fact that we might not want to
>>>     add even
>>>     > more external dependencies on pginfra than we already have...
>>>
>>>     a) "send patches" is not the only way to improve the current 
>>> state of
>>>     affairs
>>>
>>>
>>> It's one of the things that is likely to be required to make this 
>>> happen though. There's a fair amount of convincing needed,
>>
>>      I believe this argument of "send patches if you want anything to 
>> change" is pretty limited in its vision. Because there are many other 
>> ways, many of which may be much more efficient to achieve the same 
>> result.
>
> in this case please present those ways
>  or stop arguing in that direction.

     I presented already: let's use the unused (year after year) 
financial resources and bring some help. It looks to me it's really needed.


>
>>
>>      Yet I have nothing against, but after 10 emails or so I'm still 
>> waiting on the same story: can anyone provide the technical details? 
>> There is still no answer here either...
>
> considered the fact that people might expect you to look at the code 
> and come up with an analysis and proposal instead of demanding that we 
> do it for you?

     Several people have said there "there are technical difficulties to 
do so". I assume when they say that, they know what they are talking 
about. Hence, they don't need to look into the source code. I'm asking 
for high level, not low level details, that can get someone started. But 
anything seems to be a big deal...

> This is similiar to proposing something for the core database code and 
> comes across as 'I want a Multithreaded Postmaster("external 
> authentication service") now because others do it as well (Microsoft, 
> MySQL, Oracle") and I dont see any technical problems so just do it 
> now' and a response like "uhm oh it is not that easy" gets your reply 
> as "tell me every single technical issue or there is no issue"

     I believe it is a very far analogy.

>
>>
>>
>>> though honestly I think you're doing a pretty good job of dissuading 
>>> people from listening or wanting to help at the moment.
>>
>>      I don't want people to have to do anything for me. I want the 
>> people who can make a decision to realize that there is an issue with 
>> the way pg-infra is providing services to some entities of the 
>> PostgreSQL Community that are not opened up to any other entity, and 
>> this is creating a discrimination. Since this needs to be fixed, the 
>> PostgreSQL Community would need to find the way of dealing with this. 
>> It's not me who needs to convince anyone. But I'm offering help, and 
>> proposing alternatives (besides the "*no* to all" that you and others 
>> have exhibited).
>
> Again - there is still the fundamental misunderstanding that 
> "something needs to be fixed", and I not sure what "alternatives" you 
> are talking about that have been proposed?
>
>>
>>      That I'm dissuading people from listening,.. can you explain 
>> why? If I were misunderstood, I offered a very clear and detailed 
>> apology. That should have stopped any misunderstanding. Besides this, 
>> what am I doing, other than raising an important topic and bringing 
>> awareness, while offering thought and alternatives on this?
>>
>>
>>>     b) I still haven't heard any technical reason, so no, I don't know
>>>     what
>>>     is holding this back or what the technical limitations are. I
>>>     don't even
>>>     know what needs to be patched and why.
>>>
>>>
>>> The main issue that I see at the moment is that the way Community 
>>> Auth is written, authenticating through it will also share 
>>> additional PII beyond the email address used to authenticate.
>>
>>      Why? Can you elaborate? Is there any place where I can find this 
>> technical details, given that it is so hard to get any more detailed 
>> response on this email thread?
>
> see above
>
>>
>>> Obviously we could warn the user about that, but we also need to 
>>> consider how and when that would be done, i.e. would we have a flag 
>>> in the system for "external sites" that aren't run by pgInfra, which 
>>> would trigger additional consent?
>>
>>      I think this should not be needed and it's not the way other 
>> auth mechanism works. Besides this: I still see the distinction of a 
>> "external site" flawed. You are making a distinction between services 
>> and software run by privileged entities and the rest.
>
> well _you_ consider it "flawed" - for us it has been a very sucessful 
> operational model in the last decade that provided a (imho - others 
> can disagree) very reliable, modern and well managed environment for 
> the project as a whole.

     Twisting my words. It's "flawed" the distinction, not the 
operational model. What I mean is that, again as an example, the 
PostgreSQL Association in Europe should be considered the same as other 
entities of the PostgreSQL Community, and from that perspective should
be a third party as anyone else.

>
>
>>
>>
>>> Or would we omit sending the extra info to external sites? Or maybe 
>>> it would be better for us to just offer a SAML or oAuth service to 
>>> external sites?
>>
>>      oAuth should be the ideal mechanism, this is what I assumed it 
>> was and I was proposing from the beginning.
>>
>>>
>>> We would also need to consider how we deal with account deletion 
>>> requests (or if we even need to).
>>
>>      I don't see why (at least when using oAuth, and probably other 
>> mechanisms). I already commented this upthread.
>
> it is not oAuth (though not very far from it implementation wise) - 
> which already shows that this entire service was _NOT_ designed or 
> considered for the usecase you originally asked for, but you could 
> have figured that our on your own in a few minutes as well...

     I can't read a repository's source code in a few minutes. Maybe you 
can. But a bit of high level details (some bullets) could have indeed 
taken minutes to write, and minutes to read, to get that understanding.

     Now: if it is not far from oAuth, I'm even more surprised why it 
cannot be open to entities not hosted on pginfra...


     Best,

     Álvaro


-- 

Alvaro Hernandez


-----------
OnGres

On 23/9/19 21:54, Magnus Hagander wrote:
> (I am not picking a particular email to respond to here, just taking 
> the latest one in the thread. No context in the choice of email, and 
> that is why I'm not quoting any of it's contents)
>
> I have been told that I have come across as delivering personal 
> attacks in this thread. That was definitely not my intention, and I 
> sincerely apologize for that if this was how it was read.

     Yes, I said so, involving also not public communication that 
happened between us. But I really appreciate you coming on the public 
thread and saying this. Thank you very much.

>
> There are many of the technical and organisational points made in this 
> thread that I do not agree with, and I stand by not agreeing with 
> those. But those should be discussed on their own merits, and not 
> involve personal attacks.
>
> So again, my apologies for this.
>
> //Magnus
>

     This is constructive. I apologized already for what I said, which 
never had any bad intentions, but was probably clumsy language and 
anyway was taken wrongly. If anything, I wanted to show some love for 
what I believed was an underused "feature" (postgresql.org community 
login) and call for actions on several areas which I see could have more 
attention. Specially, if there are financial resources which could be 
put to good use. I also offered, and insist on, my offer to help on 
management, structure and planning.

     I will take these recommendations, at some later point, more 
carefully written, to the appropriate forums.

     For now, I believe it is better to close of this thread (at least 
from my side) and thank you again, Magnus, for this last email. Really 
appreciated.


     Best,

     Álvaro

-- 

Alvaro Hernandez


-----------
OnGres

On 9/23/19 6:09 PM, Álvaro Hernández wrote:
> 
> 
> On 23/9/19 9:28, Stefan Kaltenbrunner wrote:
>> On 9/23/19 2:20 PM, Álvaro Hernández wrote:
>>>
>>>
>>> On 23/9/19 10:26, Dave Page wrote:
>>>>
>>>>
>>>> On Sat, Sep 21, 2019 at 10:45 PM Álvaro Hernández <aht@ongres.com 
>>>> <mailto:aht@ongres.com>> wrote:
>>>>
>>>>
>>>>
>>>>     On 21/9/19 12:32, Stefan Kaltenbrunner wrote:
>>>>     > On 9/20/19 3:14 AM, Álvaro Hernández wrote:
>>>>     >>
>>>>     >
>>>>     > [...]
>>>>     >
>>>>     >>> Oh, and as a general rule, "requesting" unpaid volunteers to
>>>>     do work
>>>>     >>> for you for free is in general not a great way to get them
>>>>     >>> enthusiastic about helping out.
>>>>     >>      Did I do so? I don't recall where or when I said that.
>>>>     >>
>>>>     >>      Irrespective of this: what you say I read as:
>>>>     >>
>>>>     >> - Either volunteers, due to being unpaid, are not doing their 
>>>> job
>>>>     >> correctly (completely);
>>>>     > tbh as one of those volunteers, I kinda find it pretty
>>>>     irritating that
>>>>     > that the very first time somebody asks for community auth being
>>>>     opened
>>>>     > to non-pginfra managed sites an association of "us" not doing
>>>>     our job
>>>>     > correctly comes up just because that feature does not (and/or 
>>>> is not
>>>>     > implemented in the way you want it) do like.
>>>>
>>>>          TBQH, I'm having a really hard time to understand how this
>>>>     conclusion could be derived from my words.
>>>>
>>>>
>>>> It's exactly what I've inferred from your emails, and clearly I'm 
>>>> not alone :-(
>>>
>>>      In between this sentence you are replying to, and the next one, 
>>> there was this one which you removed from your response:
>>>
>>> "For the avoidance of doubt: Stefan, and any other pg-infra volunteer 
>>> or anyone else how felt bad about my words: my deepest and most 
>>> sincere apology. I never, under any circumstance, intended to do any 
>>> negative statement about the job done or the team itself. I have a 
>>> great deal of respect to any kind of volunteering in general, let 
>>> alone for the one on helping on the technology that I love. I have 
>>> volunteered tons of work on Postgres myself, and I cannot otherwise 
>>> that feel in the same page. pg-infra: I know the work that you do and 
>>> have done, and I really appreciate it, specially given how small team 
>>> you are."
>>>
>>>      The fact that you are still replying to the above sentence with 
>>> the paragraph that follows removed, means that either:
>>>
>>> * you didn't read it (in which case, please do);
>>
>> have you ever considered that dave just wanted to express that he had 
>> similiar feelings to what I had - simply claiming he didn't read your 
>> apology seems like a weird interpretation...
> 
>      Have you ever considered accepting, or even thanking, my apologies?
> 
>      Or at least, tell me if they are not enough for you.

The appology is for sure enough and I do accept it - thanks for saying that!




regards

Stefan