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

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