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

On 23/9/19 10:26, Dave Page wrote:
>
>
> On Sat, Sep 21, 2019 at 10:45 PM Álvaro Hernández <aht(at)ongres(dot)com
> <mailto: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 :-(

    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