On Wed, Apr 7, 2021 at 1:11 AM Simon Lees <sflees@suse.de> wrote:
On 4/7/21 12:35 PM, Neal Gompa wrote:
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: 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.
This is simply not true, all our previous planning has been based around no separation which is actually simplest from a legal perspective. Currently the data is hosted on SUSE infrastructure and therefore is owned by SUSE from a GDPR perspective. With one account system just because we now have a foundation doesn't change that fact, the data would still be owned by SUSE.
As I outlined it is beneficial to SUSE to transfer that data to openSUSE as it greatly reduces there GDPR footprint and cost of dealing with GDPR. At the same time there are only two real things that could bankrupt or put a foundation in serious financial issues one is fines for failing to maintain adaquite bookwork the other is fines from failing to handle GDPR correctly, so if (not when) the foundation decides it would like to handle data it needs to be very careful about how it decides to do that to ensure that in 10-15 years time when things and volunteers have changed we still have the capability to properly handle GDPR requests. Atleast that is the legal advice we have to date.
It is also worth noting that to this point as part of creating a foundation there has been no plan to transfer any of the openSUSE Infrastructure currently owned by SUSE to a foundation. If we did go down that path then yes separating login systems and dealing with GDPR is something that we would look at. But again as part of foundation proposals we had no immediate plans to do anything but again if we work with SUSE here and its beneficial to transfer some hardware we can look at it into the future.
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.
Atleast this is now being better thought out and planned then the original you'll just need to log in everywhere twice and or swap between.
This was always in the plan for openSUSE Accounts. The other aspect of this was to have the SUSE Bugzilla support multi-provider SSO like the Red Hat Bugzilla does, so that whether you log in with SUSE or openSUSE account system, you'll get into Bugzilla and can go on your merry way.
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.
Yeah I know the issues with the existing system especially connect (we have been trying to properly get rid of it since before I joined the board). At some point we as a board decided that connect.opensuse.org should no longer resolve and only people who really need it should be given access by an alternative means (IE those wanting to apply for membership and the membership committee). I guess this got reverted at some point.
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.
I am by no means saying don't do stuff (While i'm still not convinced about needing a 4th auth system to do my job). Just that it is wise to have all the right people onboard. The board could have initially helped in this area but we didn't find out about these plans until significant work and effort had already been invested.
If the openSUSE Chairman was going to veto us trying to fix this mess, then I would be pretty cheesed off, personally.
At the end of the day under current law SUSE is Legally responsible for all openSUSE's data under GDPR as such whenever the Heroes add a new service that stores any form of data SUSE should be comfortable with it and so id be expecting the Heroes to be running these things by the relevant people at SUSE prior to working on them so we don't end up in an awkward situation where SUSE has to tell the Heroes that you shouldn't be running that or no you can't do that. Mind you under the same reasoning I'm really supprised that SUSE hasn't invested the time and effort to migrate us away from connect because I suspect its a serious GDPR liability having it still running and at the end of the day thats there issue not openSUSE's (atleast from a GDPR perspective).
Nothing we're planning or doing adds to the data we're already collecting, so I think we're fine there. -- 真実はいつも一つ！/ Always, there's only one truth!