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

Поиск
Список
Период
Сортировка
От Álvaro Hernández
Тема Re: Using postgresql.org account as an auth id on third partywebsites
Дата
Msg-id 09c7df58-99d1-d456-ff59-7934c42939d2@ongres.com
обсуждение исходный текст
Ответ на Re: Using postgresql.org account as an auth id on third party websites  (Dave Page <dpage@pgadmin.org>)
Ответы Re: Using postgresql.org account as an auth id on third party websites  (Dave Page <dpage@pgadmin.org>)
Re: Using postgresql.org account as an auth id on third partywebsites  (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>)
Список pgsql-www


On 23/9/19 10:26, Dave Page wrote:


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

* 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

В списке pgsql-www по дате отправления:

Предыдущее
От: Dave Page
Дата:
Сообщение: Re: Using postgresql.org account as an auth id on third party websites
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Using postgresql.org account as an auth id on third party websites