Re: Using postgresql.org account as an auth id on third partywebsites

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