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

On Sat, Sep 21, 2019 at 10:45 PM Álvaro Hernández <aht(at)ongres(dot)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
:-(

> 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 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.

> 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.

> > 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, though honestly I think
you're doing a pretty good job of dissuading people from listening or
wanting to help at the moment.

> 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. 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? 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?

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

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

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company