Re: Using postgresql.org account as an auth id on third partywebsites - Mailing list pgsql-www

On 23/9/19 9:28, Stefan Kaltenbrunner wrote:
>
>>>
>>>
>>> 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.

     I agree. Happy to participate on those and EOF this thread. Thank 
you for this, it is the very first positive answer to anything that I 
have said so far.



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

     No, but well done it could. Worse case, it would help. Not doing 
anything, surely won't help. Keeping donations in the bank is not a wise 
use of those donations either.


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

     We work with customers much larger than that, with way more 
infrastructure, with much more sensitive PII data and extremely valuable 
assets that need to be protected with very strict means. Yet we help 
them run their PostgreSQL servers. We know how to do this from a legal 
and management and technical perspective, and I can only insist on 
offering my help here.

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

     What I'm saying is that there are several entities here that are 
"conflated": PostgreSQL Association of Canada, which holds the 
trademarks and AFAIK the "accepted legal estatutes" of the Community; 
and then there is other entities like EU or US that are separate legal 
entities, no different from any other entities in the PostgreSQL 
Community (say Fundación PostgreSQL or any local user group, for that 
matter). And then, there should be a separation of the 
benefits/services/etc that "members" enjoy, and they should be open to 
all under the same terms. Limited to NPOs or not. But as of today they 
aren't, and some entities are "special". I get it, it's OK they are, but 
they shouldn't be in the future. Every Community Member should have 
equal opportunities.

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

     I'm willing to help on multi-year commitments. Plus any help, even 
if temporary, is better than none.

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

     To provide a clear separation between PostgreSQL Community entities
and provide equal opportunities.

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

     I don't have anything about anybody running on pginfra. What I'm 
saying is what the rules are for that, is this open equally to any 
member? And if so: I believe postgresql.org is a service that would 
benefit the Community as a whole, and as such I advocate for it to be 
open to the ones not hosted on pg-infra, and I have repeatedly asked for 
what are the technical reasons of why this is hard (other than "go to 
the repo and look for yourself").

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

     I believe it was not addressed.

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

     I presented already: let's use the unused (year after year) 
financial resources and bring some help. It looks to me it's really needed.


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

     Several people have said there "there are technical difficulties to 
do so". I assume when they say that, they know what they are talking 
about. Hence, they don't need to look into the source code. I'm asking 
for high level, not low level details, that can get someone started. But 
anything seems to be a big deal...

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

     I believe it is a very far analogy.

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

     Twisting my words. It's "flawed" the distinction, not the 
operational model. What I mean is that, again as an example, the 
PostgreSQL Association in Europe should be considered the same as other 
entities of the PostgreSQL Community, and from that perspective should
be a third party as anyone else.

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

     I can't read a repository's source code in a few minutes. Maybe you 
can. But a bit of high level details (some bullets) could have indeed 
taken minutes to write, and minutes to read, to get that understanding.

     Now: if it is not far from oAuth, I'm even more surprised why it 
cannot be open to entities not hosted on pginfra...


     Best,

     Álvaro


-- 

Alvaro Hernandez


-----------
OnGres