[RFC][Under discussion] Create a global login system for php.net

php.internals

Aaron Junker

4 years ago
Hi all, I would like to start the discussion on my RFC for creating a global login system on php.net: https://wiki.php.net/rfc/global_login. When you have feedback to a specific point of the RFC, please use the corresponding number used in the RFC. Best regards Aaron Junker

Mark Randall

4 years ago
On 28/05/2022 10:53, Aaron Junker wrote:
> When you have feedback to a specific point of the RFC, please use the corresponding number used in the RFC.
To point 1, there was a time I was thinking about implementing a system ourselves (I was working on website prototypes at the time). That being said, as you identified creating our own system requires resources we don't have, and PHP is bad at infrastructure (lack of resources / specialists). For that reason I think the sensible thing to do would be to use Github.

Wang Lei

4 years ago
1.2 Type of global login system It would be great if Github could be used for the global login. I started to work on PHP several months ago. For a new developer, I felt the most frustrating thing was I could not login the different systems of PHP with one account. I understand that PHP is a long-history project. And moving to a modern infrastructure needs lots of effort. I think that creating a global login system is definitely a good beginning. Thanks, -Steven 在 2022年5月28日 +0800 PM5:53,Aaron Junker <aaron.junker@outlook.com>,写道:

Andreas Heigl

4 years ago
Hey All. On 28.05.22 11:53, Aaron Junker wrote:
> Hi all, > > I would like to start the discussion on my RFC for creating a global login system on php.net: https://wiki.php.net/rfc/global_login. > > When you have feedback to a specific point of the RFC, please use the corresponding number used in the RFC.
I do have my issues with the general RFC. The idea to have one login system to all parts of the PHP internals ecosystem seems tempting for sure. But as you pointed out in the introduction, there are 9 different services - partly rather old ones - that would require some work to make SSO work. Some of them we have control over, some of them we do not (as those are external applications that we are using. Fiddling with their sourcecode might be possible but will leave us more or less unable to update the tools) So moving those applications that we have control over towards SSO will bind resources. And not only now, but also in the future as those tools might need updates as well. Resources though, espechialy for infrastructure, are a very rare good! In addition I would say that we can assume the edit.php.net to be dead after we moved documentation from SVN to git. So that is awesome as that means "one down" and we couldn't already find someone to modify edit.php.net to work with git instead of SVN. So that's great news! But the bad news is, that there is also the colobus system which powers the NNTP-server backend that a number of people use to interact with the mailing-list. Which also has an authentication and would therefore need to be switched. So we are back at 9 services. And we switched one that is completely under our control to one that isn't as we are merely using a (rather old by now) service. And there might even be more than those. So what I'm trying to bring across here is that this task will bind a lot of resources with a gain that I'm not sure is worth the effort. And instead of binding people working on resources that improve the life of a few (those working on these quirky systems) I'd rather see those resources spent where they improve the life of all PHP-Developers. Like improving the docs, triaging bugs, answering questions on StackOverflow/Room11/PHPC/Whatever else there is. In addition to that I would like to raise my concerns over using GitHub login for everything (Topic 1.2). GitHub is a company based in the US and therefore bound to US law. That already means that people from certain countries can not (easily) collaborate and are therefore also excluded from contributing in any way to PHP[1]. In addition to those regulations directly by GitHub some countries are blocking access to GitHub on their own account which means that Developers from Russia or China will have a harder time contributing to PHP due to the fact that they are not able to login into any system. Are we aware of that? On the other hand maintaining our own SSO-Solution will bind even more resources... See above. In addition: The number of different logins is usually rather small per person. And keeping track of the different systems and passwords via a PasswordManager should solve most of the day-to-day hassle. Having a central place though to document the hassle would be a very helpful addition to the PHP ecosystem! My 0.02€ Cheers Andreas - The one having struggled for some years with just *one* infra-change. [1] https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls#on-which-countries-and-territories-are-us-government-sanctions-applied
> > Best regards > Aaron Junker >
-- ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+

Aaron Junker

4 years ago
Hi Andreas
> In addition I would say that we can assume the edit.php.net to be dead after > we moved documentation from SVN to git. So that is awesome as that > means "one down" and we couldn't already find someone to modify > edit.php.net to work with git instead of SVN. So that's great news!
Good point. Will add this to my RFC. I was not aware of this.
> GitHub is a company based in the US and therefore bound to US law. That > already means that people from certain countries can not (easily) collaborate > and are therefore also excluded from contributing in any way to PHP[1]. In > addition to those regulations directly by GitHub some countries are blocking > access to GitHub on their own account which means that Developers from > Russia or China will have a harder time contributing to PHP due to the fact > that they are not able to login into any system. > > Are we aware of that?
I think that's an issue many people had when PHP moved to GitHub. But now development is already on GitHub, so in my opinion there isn't a big issue with that (beside of course that they can't participate in general). For your concerns regarding human resources, I would do everything needed to bring such a system to existence. Best regards Aaron Junker

Ben Ramsey

4 years ago
On 5/29/22 09:57, Andreas Heigl wrote:
> But the bad news is, that there is also the colobus system which powers > the NNTP-server backend that a number of people use to interact with the > mailing-list. Which also has an authentication and would therefore need > to be switched. So we are back at 9 services. And we switched one that > is completely under our control to one that isn't as we are merely using > a (rather old by now) service.
I've looked into colobus a fair amount, and it does not use authentication itself. It accepts requests to post to newgroups, but then it appears to primarily act as a proxy for ezmlm, which has it's own form of authentication, and we're not going to be able to tie the ezmlm authentication to GitHub.
-- Cheers, Ben

Aaron Junker

4 years ago
Hi all, I've edited my RFC[1], so it now contains a note that edit.php.net is currently not in a usable state. Besides that, I didn't find any big points that could have been added to the RFC. So, unless a big new discussion starts, I will open votes this Saturday.  But I have two questions: 1. What kind of majority in votes will this RFC need to get accepted?  2. Am I allowed to vote on my own RFC?  Best regards  Aaron Junker  [1] https://wiki.php.net/rfc/global_login

Rowan Collins

4 years ago
On 08/06/2022 20:22, Aaron Junker wrote:
> But I have two questions: > > 1. What kind of majority in votes will this RFC need to get accepted? > 2. Am I allowed to vote on my own RFC?
While this is a somewhat unusual RFC, because it's a change to the project / infrastructure, not the language itself, it should still follow the rules here: https://wiki.php.net/RFC/voting Question 1 is straight-forward: "The primary vote of an RFC, determining overall acceptance of the proposal, may only have two voting options and requires a 2/3 majority. ... [Secondary] votes may have more than two voting options and may be decided by simple plurality."  So the overall RFC requires a two-thirds majority; the others can be simple plurality (but you should probably make that explicit on the voting form). Question 2 is also covered on that page, although the wording is a bit odd. The proposer of the RFC is not *disqualified* from voting, but they are not automatically *eligible* to vote. So, if you can vote on RFCs in general, you can vote on this one. Specifically, as noted at https://wiki.php.net/rfc/howto "Note that RFC karma does not automatically give you karma to vote." Regards,
-- Rowan Tommins [IMSoP]

Derick Rethans

4 years ago
On 8 June 2022 20:22:46 BST, Aaron Junker <aaron.junker@outlook.com> wrote:
>Hi all, > >I've edited my RFC[1], so it now contains a note that edit.php.net is currently not in a usable state. > >Besides that, I didn't find any big points that could have been added to the RFC. > >So, unless a big new discussion starts, I will open votes this Saturday.  > >But I have two questions: > >1. What kind of majority in votes will this RFC need to get accepted? 
Everything is ⅔ now.
>2. Am I allowed to vote on my own RFC?
If you have voting rights, sure. However, I'm thinking that you're massively underestimating the work that is involved to implement this, and some of it might not be possible (for example coralling dokuwiki to use this style of logging in). Personally, I'm questioning whether it's really worth the effort. I don't think I'll be voting in favour, as I'm going to guess that I'll end up having to support a lot of this. cheers Derick