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

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