On Tue, Apr 6, 2021 at 8:24 PM Simon Lees <sflees@suse.de> wrote:
On 4/6/21 5:59 PM, Sasi Olin wrote:
On Di, Apr 6, 2021 at 09:55, Lars Vogdt <lrupp@suse.de> wrote:
Let me vote for Nextcloud/Owncloud here: * multiple groups can be created/administrated * has a (public) calendar (another item on the ToDo list) * could be used to provide all members a place for collaboration (files, images, cookbook, ...) - while I'm not sure if we should pay our members some MB space for their work? * could even obsolete users.o.o directly * ...
We could create a mail ticket system on pagure for membership submissions and obsolete connect right now, the much bigger problem is membership applications than keeping existing memberships.
Handling applications is actually the easy bit, we probably don't need anything more then a email template that you fill out and email to a mailing list. It is then streamlining the process of accepting the membership setting up the email / irc aliases if desired etc is probably what actually needs atleast a little work.
I still vote we do membership management in the login system because: * that allows us to do login for members-only services global instead of implementing the list of members per service * we need to have our own login system for gdpr/foundation reasons anyway (that was discussed during gdpr meeting last year)
I am not entirely convinced that "Need" is the right word here. Certainly SUSE Legal would prefer not to be responsible from a GDPR perspective, however there are other things at play here.
It would be exceptionally unwise for a "openSUSE Fountdation" to take ownership of user data unless as part of SUSE's sponsorship of openSUSE it covers these costs. To date as part of our foundation discussions we have always seen this as a possible future option but not something that would be done straight away but something that could be discussed later if both sides agree it would be beneficial given there are also significant technical challenges here that i'll get to in a minute.
Having said that it should be considerably cheaper for openSUSE to handle its GDPR then what it costs SUSE Legal, so if SUSE Legal really wants such a change it would be really helpful if they help us develop a business case and outline how the above would work to go to upper SUSE management to help push the foundation proposal forward.
Separation of account systems *must* happen before separation of legal entities anyway. It would be dumb to do a "trial-by-fire" for this particular thing as it could land both SUSE and openSUSE in a lot of hot water.
As I said earlier there were technical reasons which have been the main reason behind not looking at this during the formation of the foundation (It's also worth noting when we last had these serious discussions SUSE IT was still in the middle of a carve out). The main ones as you mention are obviously obs and bugzilla, data gets shared from the openSUSE obs instance to the internal one and as you are aware the bugzilla instance is the same.
What makes this problem genuinely hard is there are a number of SUSE employees such as myself who were members of the openSUSE community before joining SUSE, to make our lives easier generally we just continue using our "community" account inside SUSE and just have the SUSE Employee flag set. This means we don't need to constantly swap obs and bugzilla accounts based off whether we are dealing with a package we maintained before joining SUSE or one we maintain as a part of our role. Further to that if an employee leaves SUSE generally it doesn't mean that all there maintainership rights etc in obs should be removed that is generally left up to them.
So under this idea of two account systems does an employee such as myself end up with a "SUSE" account and a "Community" account if so which has access to what inside obs and how do you make sure that my bugs for community packages still get assigned to my SUSE account with access to security bugs because that is the bugzilla account i'll use.
Let's talk about the world where there are two account systems. In this world, the openSUSE account system would be told to associate you with your SUSE Bugzilla account by means of you setting your SUSE Bugzilla email address override. This is already supported in the Noggin system that Sasi and I wish to deploy for openSUSE, and Fedora's instance uses it to allow people to override the email address used to link Fedora accounts to the Red Hat Bugzilla system. This situation has existed in Fedora for many years and has a solution built right into the platform that we can use.
Really if SUSE Legal no longer wants to be legally responsible for community data from a GDPR perspective they need to first work with the openSUSE community to help us establish a foundation that can hold the data and then need to work with SUSE IT and then the heroes to answer the above questions but really currently its still mostly SUSE IT's responsibility and if they come back to SUSE Legal and say yes we can do that but its going to cost $XXXXXX SUSE Legal might turn around and say well if the cost is that much its not worth the benefit and instead we will stick with the existing arrangement.
There are also other technical solutions to this problem that would address these issues in a far simpler manner. For example it maybe possible to have multiple IDP databases such that the employee database is on SUSE hardware and the community one is on foundation hardware, which would solve the GDPR issue from a legal perspective. The foundation could then have a "Service agreement" with SUSE IT to maintain the login system and make changes in a timely fashion. As part of its sponsorship of openSUSE the agreement could also state that SUSE will provide an employee already working on openSUSE to handle GDPR requests which would be much cheaper then SUSE Legal handling them and would mean that a foundation wouldn't have to deal with the risk of not having someone on the Heroes team in 10 years time who is willing to handle GDPR requests.
Two account systems are literally the expression of "multiple IDP databases". It's all LDAP on the backend. But realistically, we would not want more than a one-way trust from openSUSE to SUSE (where extra attributes are only on the SUSE side).
The reality is any change here will benefit SUSE the most so really they need to be the one driving the process. As a board member in the current state i'd be really hesitant for the Heroes to create yet another authentication system even if it could fix all the above issues without approval from SUSE Legal and SUSE IT because ultimately currently they are still responsible for the data. Without such agreement this would be one rare case where i'd see it as reasonable for the openSUSE Chairman to use there veto.
But as a result of all this I don't think that we can expect to have a separate account system in the near future and maybe its worth using an alternate system as an intermediate step.
The current situation is pretty bad. We have the broken Connect system, an IDP that isn't particularly nice for community usage, and people subtly saying that we need to be consulting with folks who never (figuratively) take our calls when we're trying to solve problems. It's really easy to say that we can't/shouldn't do these things when you're not dealing with the consequences of that. Sasi and I deal with a lot of user support over the IDP, and the Connect system is an utter nightmare on its own. We spent *two years* funneling our own requirements into the design of Noggin so that we could have at least a decent starting point to replace this Byzantine system we have now. If the openSUSE Chairman was going to veto us trying to fix this mess, then I would be pretty cheesed off, personally. -- 真実はいつも一つ！/ Always, there's only one truth!