2020-06-03T00:43:02  <romulas> nm
2020-06-03T02:19:12  *** okurz_ is now known as okurz
2020-06-03T03:51:54  *** DrDro[m]14 is now known as DrDro7624[m]
2020-06-03T04:45:15  -heroes-bot- PROBLEM: PSQL locks on mirrordb2.infra.opensuse.org - POSTGRES_LOCKS CRITICAL: DB postgres total waiting locks: 20 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=mirrordb2.infra.opensuse.org&service=PSQL%20locks
2020-06-03T04:45:28  -heroes-bot- PROBLEM: PSQL locks on mirrordb1.infra.opensuse.org - POSTGRES_LOCKS CRITICAL: DB postgres total waiting locks: 7 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=mirrordb1.infra.opensuse.org&service=PSQL%20locks
2020-06-03T04:55:15  -heroes-bot- RECOVERY: PSQL locks on mirrordb2.infra.opensuse.org - POSTGRES_LOCKS OK: DB postgres total=1 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=mirrordb2.infra.opensuse.org&service=PSQL%20locks
2020-06-03T04:55:26  -heroes-bot- RECOVERY: PSQL locks on mirrordb1.infra.opensuse.org - POSTGRES_LOCKS OK: DB postgres total=8 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=mirrordb1.infra.opensuse.org&service=PSQL%20locks
2020-06-03T06:01:05  <lcp> lkocman: I wonder if you could deploy software-o-o with https://github.com/openSUSE/software-o-o/commit/470f55fd55169acf86d61b4119a79e7ec13d72cc
2020-06-03T06:01:31  <lcp> eh, he's not here
2020-06-03T06:01:40  <lcp> and also we should fix the certificate on download.opensuse.org
2020-06-03T06:12:23  <pjessen> lcp: I have just opened a ticket on that
2020-06-03T06:13:04  <lcp> I reported a ticket to at least have software-o-o link to http and not https so downloading the distros work
2020-06-03T06:13:15  <lcp> works*
2020-06-03T06:13:46  <bmwiedemann1> so it is broken at the block-device level and XFS is just reporting the issues
2020-06-03T06:22:48  <okurz> as in likely faulty hardware?
2020-06-03T06:23:47  <bmwiedemann1> maybe.
2020-06-03T06:25:11  <okurz> btw, I'm up and ready for further openID+openQA experiments
2020-06-03T06:26:49  <okurz> bmwiedemann1: so I added /etc/hosts entries overriding www.opensuse.org with the ipsilon instance however http://okurz-vm.qa/login yields Forbidden. Probably because "https://www.opensuse.org/openid/user/" doesn't resolve properly on the ipsilon instance
2020-06-03T06:38:17  <bmwiedemann1> okurz: looks a bit better now. I adjusted redirects on ipsilon.
2020-06-03T06:39:11  <okurz> I'd even say it looks very good :)
2020-06-03T06:39:38  <okurz> as in, I think I am the same user as on the old openID server
2020-06-03T06:40:29  <okurz> so with this I assume the only thing left is to switch the redirect on w3 again?
2020-06-03T06:40:35  <bmwiedemann1> but I noticed that login went through www.opensuse.org/login now, which does not exist yet
2020-06-03T06:43:31  <bmwiedemann1> OK. let's try to switch on w3
2020-06-03T06:57:54  <okurz> bmwiedemann1: "unexpected_url_redirect: Discovery for the given ID ended up at the wrong place" when returning back from ipsilon
2020-06-03T07:01:51  <pjessen> is anyone working on the mirrors listing page?  something is not right with the shading of alternating lines
2020-06-03T07:01:58  <okurz> bmwiedemann1: it also fails on http://okurz-vm.qa/ now which should still directly point to id.opensuse.org
2020-06-03T07:03:18  <bmwiedemann1> okurz: works there now
2020-06-03T07:03:33  <bmwiedemann1> I changed the redirect on w3 into a proxy
2020-06-03T07:03:58  <bmwiedemann1> the perl openID consumer did not like the id.o.o vs www.o.o mismatch
2020-06-03T07:03:59  <okurz> nice, that looks better :)
2020-06-03T07:04:22  <okurz> yeah I guess for authentication system one has to be a bit more picky when you want to trust ;)
2020-06-03T07:15:59  <bmwiedemann1> OK, now how do we tell users about that change? I'll update idp-portal-info as the first step.
2020-06-03T07:17:54  <okurz> that's good.
2020-06-03T07:18:36  <okurz> do you want to declare it production-ready already? I did not see further problems. I could update all openSUSE users using opensuse-factory and SUSE internal using openqa@suse.de
2020-06-03T07:22:01  <bmwiedemann1> I just hit some other problem. The authorization step does not work here
2020-06-03T07:23:07  <bmwiedemann1> and there is more to do for it to be production-ready.
2020-06-03T07:23:14  <bmwiedemann1> e.g. proper DB and backups
2020-06-03T07:24:59  <okurz> so I would wait until we more widely announce that
2020-06-03T07:26:28  <bmwiedemann1> oh and if we proxy on w3, then the assets are missing :-(
2020-06-03T07:31:01  <okurz> what are assets?
2020-06-03T07:33:55  <bmwiedemann1> .css and images
2020-06-03T07:34:20  <bmwiedemann1> so when you ctrl-shift-r in firefox to force-reload, the auth page looks rather gray
2020-06-03T07:35:01  <okurz> but https://id.opensuse.org/ looks the same
2020-06-03T07:35:06  <darix> why do you want to proxy twice?
2020-06-03T07:35:15  <darix> you can split based on subpaths on haproxy as well
2020-06-03T07:35:21  <darix> you can rewrite urls in haproxy
2020-06-03T07:35:32  <darix> you can even rewrite headers in haproxy (i can show you an example for this)
2020-06-03T07:42:48  <okurz> bmwiedemann1: just wondering, what's the worst that could happen if your instance dies again with lost or corrupted sqlite database? Users would need to login again but openQA would consider them the same user if the URL+name+email is the same, so nothing lost?
2020-06-03T07:44:26  <bmwiedemann1> they would have to confirm again that they trust the site with their name+email
2020-06-03T07:44:50  <bmwiedemann1> found a nice way to make the assets work
2020-06-03T07:46:01  <okurz> I don't see a problem with the re-trust. Unless you disagree I would declare the current approach as usable by all as it's not worse than the previous situation and you fixed the major problem of conflicting user entries from yesterday
2020-06-03T07:47:36  <bmwiedemann1> OK
2020-06-03T07:52:18  <bmwiedemann1> http://idp-portal-info.suse.com/ is updated
2020-06-03T07:57:33  <okurz> bmwiedemann1: thanks a lot, openQA hero from the first hour to now ;)
2020-06-03T08:00:00  *** ldevulder_ is now known as ldevulder
2020-06-03T08:00:02  *** Martchus_ is now known as Martchus
2020-06-03T08:00:46  <bmwiedemann1> for some reason, it fails in chromium, but works in firefox.
2020-06-03T08:00:47  <Martchus> Seems like the system is still in development mode. At least I've just been confronted with an internal Python stack trace which even contained some key: https://paste.opensuse.org/48286704
2020-06-03T08:01:13  <Martchus> bmwiedemann1: And yes, I've noticed the same difference between the browsers. I'm not getting that error in firefox.
2020-06-03T08:02:28  <Martchus> But in Firefox I'm getting '401 - Unauthorized; Transaction expired, or cookies not available'.
2020-06-03T08:04:04  <bmwiedemann1> hmm. could it be, that it gets confused by www.o.o cookies content?
2020-06-03T08:04:19  <bmwiedemann1> Illegal cookie name JSESSIONID
2020-06-03T08:05:21  <okurz> so seems like that broke it now
2020-06-03T08:07:52  <bmwiedemann1> ah, so it only worked when there were previous cookies stored. and with a fresh browser it fails with 401 :-(
2020-06-03T08:09:10  <okurz> I must admit after you switched to w3 again I think I only tested with my cookie-storing browser
2020-06-03T08:13:23  <bmwiedemann1> so probably id.o.o stores cookies for that domain only and those are not available on www.o.o
2020-06-03T08:22:24  <okurz> could this be worked around with subpath based splitting on haproxy as suggested by darix?
2020-06-03T08:24:02  <bmwiedemann1> okurz: works now. Finally maintaining a http-proxy and related web-tool with logins for a decade paid off.
2020-06-03T08:26:33  <okurz> good. let's go back to user testing :)
2020-06-03T08:27:26  <darix> okurz: tbh ... I would kill that whole www.opensuse.org/openid/ thing
2020-06-03T08:27:32  <darix> and force everyone to use the new URL
2020-06-03T08:30:11  <okurz> darix: go ahead and inform whoever is "everyone" :)
2020-06-03T08:30:37  <okurz> Actually I would be ok to change the URL but not in a rush as a workaround to MF-IT not reacting on the other instance dying
2020-06-03T08:31:52  <darix> put a static page on /openid/ to tell people "please talk to the admin of the service. this provider is now deprecated"
2020-06-03T08:31:58  <darix> after announcing it on opensuse-project
2020-06-03T08:31:59  <darix> done
2020-06-03T08:32:26  <darix> i mean changing one url in their config cant be that hard
2020-06-03T08:32:44  <lcp> the problem is that we don't know WHO has the url set where
2020-06-03T08:32:45  <darix> you could even put the new url on that page so they have all needed informations
2020-06-03T08:32:47  <bmwiedemann1> and I just noticed that it always asks for password now, even if still logged in
2020-06-03T08:32:50  <darix> lcp: so what?
2020-06-03T08:32:59  <darix> lcp: you argued that the old path was bad
2020-06-03T08:33:00  <lcp> because you can sign up on any service that has openid on the internet
2020-06-03T08:33:03  <darix> why do you want to keep it?
2020-06-03T08:33:13  <lcp> so in this case it means some people lose access to their stuff
2020-06-03T08:33:17  <lcp> without prior warning
2020-06-03T08:33:28  <darix> so send out the warning now and give them 4 weeks to fix things
2020-06-03T08:33:33  <lcp> no, I want to have a prior warning so people can move
2020-06-03T08:33:42  <lcp> that means we have to keep up this url for a moment
2020-06-03T08:33:46  <bmwiedemann1> darix: we still need to have a discussion about the future openID URL.
2020-06-03T08:33:57  <darix> that way you actually learn who is using it where
2020-06-03T08:34:09  <darix> id.opensuse.org I thought?
2020-06-03T08:34:18  <darix> isnt that the path you are using now?
2020-06-03T08:34:22  <lcp> darix: providers will not fix things, the user have to move accounts
2020-06-03T08:34:31  <lcp> most providers at least
2020-06-03T08:34:32  <bmwiedemann1> I am using it, but it might not be good enough in future
2020-06-03T08:34:47  <darix> bmwiedemann1: then you want to switch it off that url
2020-06-03T08:34:51  <lcp> we have some ability to move over in case of openqa, weblate and ci
2020-06-03T08:34:54  <darix> until you have decided what to use
2020-06-03T08:35:07  <darix> you are creating facts already
2020-06-03T08:35:27  <bmwiedemann1> I know. MF-IT was supposed to provide their service for 3 more weeks
2020-06-03T08:35:38  <darix> so have that discussion now?
2020-06-03T08:35:40  <lcp> id.opensuse.org interferes with wikis schema
2020-06-03T08:35:54  <darix> lcp: that wiki scheme interface with everything
2020-06-03T08:35:56  <lcp> prevents the indonesian community from having their wiki
2020-06-03T08:36:13  <lcp> it does, but nobody posted a ticket to change it
2020-06-03T08:36:45  <bmwiedemann1> lcp: id.wiki.opensuse.org sounds much better
2020-06-03T08:36:50  <darix> ^
2020-06-03T08:37:01  <lcp> no
2020-06-03T08:37:08  <lcp> wiki.opensuse.org/id
2020-06-03T08:37:26  <lcp> I really don't think we need more certificates for more subdomains
2020-06-03T08:37:29  <darix> can mediawiki do that schema?
2020-06-03T08:37:36  <lcp> it can
2020-06-03T08:37:45  <darix> lcp: we dont care about certs.
2020-06-03T08:37:49  <darix> that part is automated
2020-06-03T08:38:06  <darix> we dont pay for it ... unlike in the past
2020-06-03T08:38:24  <Martchus> bmwiedemann1: thanks, after clearing my cookies it now works in chromium as well
2020-06-03T08:38:40  <lcp> sure, I just don't think we need more, considering that we can't manage the existing one in download.opensuse.org ;)
2020-06-03T08:38:42  <Martchus> however, when it didn't work I still got the raw error message
2020-06-03T08:38:44  <lcp> due to the mirror issue, but still
2020-06-03T08:38:49  <darix> so will we be sure that sso.opensuse.org will never interfer with language codes?
2020-06-03T08:38:52  <darix> then we could just do that
2020-06-03T08:39:05  <lcp> yeah, sso is a better idea probably
2020-06-03T08:39:06  <darix> lcp: the download.o.o cert should be fixed
2020-06-03T08:39:06  <Martchus> I still think this service should be set to production mode instead of leaking internal backtraces
2020-06-03T08:39:16  <lcp> darix: glad to hear that
2020-06-03T08:39:43  <darix> so
2020-06-03T08:39:50  <darix> sso.opensuse.org it is then?
2020-06-03T08:39:56  <bmwiedemann1> Martchus: I set debug=False now. I hope that does the trick.
2020-06-03T08:40:32  <Martchus> bmwiedemann1: thanks; unfortunately I've now cleared my cookie so I'm not sure how to cross-check
2020-06-03T08:41:19  <lcp> darix: yeah, and let's discuss with cboltz later to move over wikis ;)
2020-06-03T08:41:20  <darix> Martchus: we will know if someone else runs into it
2020-06-03T08:41:50  <bmwiedemann1> darix: there is the common criteria thing were SUSE needs to be in control of stuff - and that includes our credentials and I think that would not work easily when people enter their passwords under a .opensuse.org domain
2020-06-03T08:42:32  <bmwiedemann1> e.g. old MF logins went through a MF-provided domain
2020-06-03T08:42:39  <Martchus> Regarding "URL breakage": It is of course simple to change the URL but unfortunately openQA so far "promotes" the old URL as a default and uses the full URL to identify users. So breaking the old URL means rushing us into changing openQA and admins to update their openQA instances. And yes, that's mainly an issue on the openQA-side but it is as it is so I'd prefer keeping the old URL around for a while.
2020-06-03T08:43:15  <darix> Martchus: we should provide openQA admins with a script that fixes their DB
2020-06-03T08:43:26  <darix> bmwiedemann1:
2020-06-03T08:43:51  <darix> bmwiedemann1: this is wrong
2020-06-03T08:44:10  <darix> bmwiedemann1: only services hosted in provo went through an mf based url
2020-06-03T08:44:22  <darix> nbg service have been opensuse.org only from the start
2020-06-03T08:45:30  <darix> so you could make DNS suse only controlled again
2020-06-03T08:45:50  <bmwiedemann1> that would make lcp unhappz
2020-06-03T08:46:16  <darix> well I just wanted to set the facts straight :)
2020-06-03T08:47:10  <lcp> eh?
2020-06-03T08:47:44  <bmwiedemann1> I want some login.securesusedomain.tld and no password forms under .o.o
2020-06-03T08:47:54  <kl_eisbaer> bmwiedemann: JFYI: I added https://status.opensuse.org/incidents/232 now to reflect the current status of openQA
2020-06-03T08:47:55  <darix> bmwiedemann1: this is not how it works
2020-06-03T08:48:08  <darix> it will never work like this unless you really switch off all login proxies
2020-06-03T08:48:17  <kl_eisbaer> I hope this avoids too many tickets/requests
2020-06-03T08:48:22  <lcp> that's good, from the start I wanted the SUSE account to be visibly SUSE
2020-06-03T08:48:42  <darix> you know the current scheme we use for most services on opensuse
2020-06-03T08:48:52  <bmwiedemann1> kl_eisbaer: openid should be back working for ~1h
2020-06-03T08:49:08  <darix> if you want to migrate the OBS to use openid connect or so ... then you have to fix osc as well
2020-06-03T08:49:16  <kl_eisbaer> bmwiedemann perfect, thanks! Feel free to update the status board once this is done :-)
2020-06-03T08:49:25  <darix> and we are not moving OBS out of the opensuse.org domain
2020-06-03T08:49:31  <bmwiedemann1> darix: yes, indeed. or saml or whatever
2020-06-03T08:49:39  <lcp> darix: all of the openSUSE services support openid/openidc or saml in some capacity, so that's possible, but we would need metadata for setting them up
2020-06-03T08:49:42  <darix> bmwiedemann1: saml with cmdline tools is no fun
2020-06-03T08:49:45  <lcp> except OBS
2020-06-03T08:50:13  <darix> it will probably mean we need service passwords in OBS to make OSC work
2020-06-03T08:50:19  <darix> which is not a minimal amount of work
2020-06-03T08:50:33  <darix> so take back opensuse.org dns control if you are worried about it
2020-06-03T08:50:39  <lcp> OSC support session keys already, so that should be simple to do
2020-06-03T08:50:56  <lcp> OBS I mean, OSC doesn't yet
2020-06-03T08:51:13  <darix> lcp: you refer to "osc token" stuff?
2020-06-03T08:51:18  <darix> that is limited to what it can do
2020-06-03T08:51:45  <bmwiedemann1> I wonder if digest auth would be a cheap way out
2020-06-03T08:52:11  <lcp> but yeah, discussing OBS auth is a pain, because in general how OBS does auth is kinda stupid
2020-06-03T08:52:35  <okurz> bmwiedemann1: one issue we saw is that previous approach preserved casing in the username. There was e.g. a user "Xiaojing_liu" that now is turned into "xiaojing_liu" with the lower case leading "x"
2020-06-03T08:52:39  <lcp> since it has multiple providers and most of them are broken in some way
2020-06-03T08:53:31  <lcp> okurz: afaik the users have to be unique in a capitalization independent way
2020-06-03T08:53:41  <lcp> so that doesn't matter in the end
2020-06-03T08:53:53  <bmwiedemann1> okurz: LDAP has it with upper-case
2020-06-03T08:54:40  <darix> bmwiedemann1: why is the IDP lowercasing it?
2020-06-03T08:54:54  <okurz> lcp: well, it looks like it is not unique because casing seems to be lost now on the way from LDAP to ipsilon
2020-06-03T08:57:55  <lcp> well, is is still unique, and lowercasing is probably just to prevent people from logging in with UsErNaMe instead of Username, so it lowercases the whole thing
2020-06-03T08:58:50  <lcp> afaik that was a problem with krb5, so I wouldn't be surprised it's done globally in ipsilon
2020-06-03T09:01:38  <bmwiedemann1> okurz: maybe openqa should lowercase the ID as well, so it matches again?
2020-06-03T09:01:53  <okurz> maybe …
2020-06-03T09:02:25  <Martchus> kl_eisbaer: By the way, that incidents page does not have the best text color vs. background color contrast.
2020-06-03T09:03:16  <lcp> Martchus: I will take care of the CSS there at some point >:D
2020-06-03T09:03:23  <lcp> it's a nightmare tho
2020-06-03T09:03:58  <Martchus> :-)
2020-06-03T09:05:27  <Martchus> okurz: By the way, I'm cleaning the database entries for users with https://id.opensuse.org URLs on our instances now.
2020-06-03T09:07:37  <Martchus> Mh… seems some of the users already gave them admin rights under their "new" accounts. So at least the first one had to manually mess with the database for that.
2020-06-03T09:08:10  <Martchus> s/them/themselves/
2020-06-03T09:11:24  <Martchus> And regarding the case: It *seems* the case had been restored at some point. E.g. we have "https://id.opensuse.org/idp/openid/id/jrivrain/" created on 2020-06-02 13:18:17 and "https://id.opensuse.org/idp/openid/id/JRivrain/" created on 2020-06-02 14:20:49.
2020-06-03T09:11:43  <Martchus> So the case-fixing must have happend between these timestamps.
2020-06-03T09:18:20  <pjessen> I see openSUSE_html_header was changed only a few days ago ?
2020-06-03T09:23:27  <pjessen> as well as the css.
2020-06-03T09:37:47  <bmwiedemann1> Martchus: maybe it depends on how the user types its username?
2020-06-03T09:39:44  <bmwiedemann1> Martchus: yes, I tested it and ipsilon just keeps the upper/lower case of what the login used
2020-06-03T09:40:04  <bmwiedemann1> even pops up a new authorization dialog, so it does not map users internally
2020-06-03T09:40:35  <bmwiedemann1> okurz: ^ is actually good news for Xiaojing_liu
2020-06-03T09:42:01  <Martchus> bmwiedemann1: I've tested it as well. So the number of different spellings of my user name which only differ by case determines how many "internal openQA users" I am able to create.
2020-06-03T09:43:26  <bmwiedemann1> yes
2020-06-03T09:44:28  <bmwiedemann1> lcp: I think, ipsilon should use what is in LDAP and not what the user used for login this time.
2020-06-03T09:45:43  <lcp> that probably is how it should be
2020-06-03T09:49:41  <bmwiedemann1> = https://pagure.io/ipsilon/issue/334
2020-06-03T09:51:26  -heroes-bot- PROBLEM: PSQL locks on mirrordb1.infra.opensuse.org - POSTGRES_LOCKS CRITICAL: DB postgres total locks: 65 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=mirrordb1.infra.opensuse.org&service=PSQL%20locks
2020-06-03T09:52:33  <lcp> kl_eisbaer: how is the header on status.o.o added to the page?
2020-06-03T09:55:01  <bmwiedemann1> https://pagure.io/fork/bmwiedemann/ipsilon/commits/devel contains my custom ipsilon hacks. I guess, some can be merged back.
2020-06-03T10:14:38  <Martchus> Yes, some look worth upstreaming.
2020-06-03T10:17:04  <Martchus> bmwiedemann1: By the way, I'm currently wondering how to improve openQA. One obvious point is to make it case insensitive. Another point is *not* to use the full URL as ID. You said that only using the nickname (the part in the path after `…/id/`) would be sufficient. How do you come to that conclusion? I'm only asking because I'm not very familiar with OpenID and don't want to break security. After a brief search it looks like
2020-06-03T10:17:05  <Martchus> usually the full URL is treated as "the ID", e.g. https://en.wikipedia.org/wiki/OpenID#Identifiers always talks about URLs
2020-06-03T10:19:57  <Martchus> We could of course only use the part after `…/id/` to map users but at the same time validate that everything before matches our generally configured OpenID provider URL. That should definitely prevent users from using a different OpenID provider while still being flexible about configuring the concrete URL.
2020-06-03T10:20:46  <Martchus> okurz: Of course your opinion would be interesting to hear as well.
2020-06-03T10:31:26  -heroes-bot- RECOVERY: PSQL locks on mirrordb1.infra.opensuse.org - POSTGRES_LOCKS OK: DB postgres total=49 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=mirrordb1.infra.opensuse.org&service=PSQL%20locks
2020-06-03T10:33:35  <lcp> Martchus: the problem with only using the username is that it may not work with other setups, as they may contain multiple id urls
2020-06-03T10:33:42  <lcp> and may even use multiple providers
2020-06-03T10:42:46  <darix> bmwiedemann1: so is sso.opensuse.org final?
2020-06-03T10:42:52  <darix> bmwiedemann1: got time for a query?
2020-06-03T10:43:27  <Martchus> lcp: What do you mean with other setups? Do you mean other "openQA setups"? If an openQA setup so far contains multiple "internal users" which only differ by the OpenID nickname they would needed be merged together via an automatic database migration.
2020-06-03T10:45:11  <Martchus> I don't think that openQA allows using multiple providers at once so we don't need to care about that.
2020-06-03T11:06:26  <kl_eisbaer> lcp: let me create an account on status.o.o for you. That makes it easier ;-)
2020-06-03T11:07:30  <kl_eisbaer> lcp: mail to your opensuse.org address is out
2020-06-03T11:08:05  <kl_eisbaer> just ping me once you managed to log in
2020-06-03T11:08:15  <okurz> Martchus: Treating the username case-insensitive only within openQA makes sense to me regardless if the provider server is changed to use the LDAP entry instead of the typed string
2020-06-03T11:10:58  <Martchus> okurz: Good. The tricky part is of course the question about the full URL.
2020-06-03T11:11:49  <okurz> yeah, there I would really stick with recommendations from specifications, e.g. the description link you provided
2020-06-03T11:38:59  <kalikiana> Martchus: "in the context of our account database" might be what's  missing to make the assertion correct? our usernames are immutable and unique. the same is not true of openid in general.
2020-06-03T11:44:41  <Martchus> kalikiana: Which assertion are you referring to? An account authenticated by a certain OpenID provider account must have *something* unique (generally).
2020-06-03T11:46:15  <kalikiana> Yes. An that's the URL. Conceptually you prove that you own the URL. Things like email/nickname/fullname are metadata.
2020-06-03T11:46:24  <Martchus> okurz: It would just be nice if the URL of the OpenID provider could be easily reconfigured.
2020-06-03T11:46:44  <kalikiana> I was referring to the nickname supposedly being unique and something we can rely on - technically we don't have a nickname here
2020-06-03T11:46:55  <kalikiana> But this is us vs. the spec
2020-06-03T11:48:04  <Martchus> kalikiana: Ok, so that's what you mean. Note that when I've been using the term "nickname" I was referring to the part in the path after `…/id/`. So I was referring to a part of the URL and *not* to additional meta-data.
2020-06-03T11:50:05  <kalikiana> Martchus: Right. The auth plugin in OpenQA does some parsing on that, so the URL is taken apart if there's no nickname in the metadata.
2020-06-03T11:55:26  <Martchus> The idea mentioned earlier explained by an example: So far we have e.g. "https://www.opensuse.org/openid/user/JRivrain" as unique ID in our database. A database migration would reduce that to "jrivrain". When a user tries to login with the URL "https://www.opensuse.org/openid/user/JRivrain" we match whether the lowercase version of "JRivrain" with the database. We also check whether everything in the URL before "JRivrain" matches
2020-06-03T11:55:27  <Martchus> the *currently* configured OpenID provider. The "currently" part is important because that allows for the flexibility of reconfiguring the OpenID provider URL e.g. from `https://www.opensuse.org/openid/user/` to `https://id.opensuse.org/idp/openid/id/` in the future.
2020-06-03T11:56:39  <Martchus> Of course for new users we would store "jrivrain" in the first place.
2020-06-03T11:57:24  <Martchus> I suppose it would be safe because we still validate the full URL to check whether it matches the expected OpenID provider URL (which might change at some point).
2020-06-03T11:58:25  <Martchus> By the way, I wasn't able to find anything about case sensitivity in https://openid.net/specs/openid-authentication-2_0.html.
2020-06-03T12:08:13  <Eighth_Doctor> bmwiedemann, bmwiedemann1: I don't think I'm supposed to alter what is returned by OpenID
2020-06-03T12:08:35  <kalikiana> Martchus: I would assume that we still store the URL in the database, and only map/compare on the fly. Because otherwise it breaks other OpenID providers
2020-06-03T12:08:37  <Eighth_Doctor> at least based on what the normalization info in the spec says: https://openid.net/specs/openid-authentication-2_0.html#normalization
2020-06-03T12:10:57  <kalikiana> Martchus: In the context of OAuth2/OpenID Connect I was actually wondering about that as well. And since id's are only valid for the chosen provider, the database still needs to contain a name or URL to disambiguate
2020-06-03T12:11:41  <kalikiana> Unless you're assuming that the Users database would be dropped in case of a change in configuration
2020-06-03T12:12:49  <Eighth_Doctor> kalikiana: OIDC returns 'sub' property from your provider
2020-06-03T12:13:20  <Eighth_Doctor> as OIDC is client-configured to a specific endpoint, the whole "rationalization of URIs" thing isn't a problem
2020-06-03T12:21:47  <Martchus> kalikiana: That's true - we should still be able to disambiguate between different providers. Otherwise if we e.g. added GitHub support one could create a GitHub user called mkittler and use my operator/admin permissions. We could do that by using prefixes, e.g. "openid:username" vs. "github:username".
2020-06-03T12:22:38  <kalikiana> Yes, I was about to mention that. And I was actually asked about Okta support as well - in which case we might want to allow a choice of providers on the same instance
2020-06-03T12:24:01  <Martchus> Eighth_Doctor: I've also read that section of the spec. It basically "redirects" to ftp://ftp.isi.edu/in-notes/rfc3986.txt which says: "The other generic syntax components [not scheme and host] are assumed to be case-sensitive unless specifically defined otherwise by the scheme (see Section 6.2.3)."
2020-06-03T12:24:14  <Eighth_Doctor> yeah
2020-06-03T12:24:23  <lcp> kl_eisbaer: done, logged in
2020-06-03T12:24:56  <Eighth_Doctor> kalikiana: this was something that LCP and I had planned for bugzilla, actually
2020-06-03T12:25:27  <Eighth_Doctor> with the openSUSE accounts system we were working on, we would have multiple auth providers in bugzilla and you'd click a button to sign in with the correct system
2020-06-03T12:26:07  <Eighth_Doctor> this is already how the Red Hat Bugzilla works: you can see a sign-in drop-down for different providers at the top right of bugzilla.redhat.com
2020-06-03T12:27:18  <Eighth_Doctor> (you need to click on "Login" to see the selection of login options)
2020-06-03T12:28:56  <kalikiana> Yeah, that's a good example.
2020-06-03T12:36:38  <Eighth_Doctor> kalikiana: the idea is that with openSUSE accounts fully separated, the systems that require both SUSE and openSUSE could interface that way (which is pretty much only Bugzilla), and the rest would switch over to purely going through openSUSE accounts
2020-06-03T12:37:08  <Eighth_Doctor> but if more systems actually required interfacing with either, that's possible to do with oidc
2020-06-03T12:37:30  <Eighth_Doctor> you can even be clever and match them up to a single account client side
2020-06-03T12:38:04  <Eighth_Doctor> (you see this on sites that do connect with Google, GitHub, etc. while still having their own account db)
2020-06-03T12:38:28  <Eighth_Doctor> (e.g. Discourse does this)
2020-06-03T12:38:56  <lcp> technically openid is called openid because www.opensuse.org/openid/user/$username is your openid
2020-06-03T12:39:04  <Eighth_Doctor> yep
2020-06-03T12:39:43  <lcp> although the more usual $username.provider like hellcp.id.fedoraproject.org is way more convinient than that nightmare we had before ;)
2020-06-03T12:39:51  <kalikiana> Eighth_Doctor, How is Bugzilla different to OpenQA here? We have openqa.opensuse.org to consider
2020-06-03T12:40:04  <lcp> (did I mention username in the id can be a subdomain?)
2020-06-03T12:40:13  <Eighth_Doctor> kalikiana: you don't test SLE in openqa.opensuse.org
2020-06-03T12:40:26  <Eighth_Doctor> or if you do, you shouldn't ;)
2020-06-03T12:40:57  <kalikiana> Eighth_Doctor: we do on openqa.suse.de
2020-06-03T12:41:08  <Eighth_Doctor> right
2020-06-03T12:41:24  <lcp> which is internal
2020-06-03T12:41:31  <lcp> >:D
2020-06-03T12:41:32  <Eighth_Doctor> so openqa.opensuse.org would be supported by openSUSE Login, while openqa.suse.de would be supported by SUSE Login
2020-06-03T12:41:53  <kalikiana> by "SUSE Login" you mean the Community Account?
2020-06-03T12:42:08  <kalikiana> or the ipsilon?
2020-06-03T12:42:23  <lcp> ipsilon is backed by community accounts
2020-06-03T12:42:27  <lcp> at this point in time
2020-06-03T12:42:40  <kalikiana> okay, just double-checking, since this gets confusing fast
2020-06-03T12:43:38  <darix> maybe we should just replace the heroes accounts with those too to reduce the number
2020-06-03T12:44:09  <lcp> that was the idea behind openSUSE accounts
2020-06-03T12:44:31  <darix> well UCS now runs the openSUSE accounts
2020-06-03T12:44:40  <lcp> freeipa backend that would be used for heroes and ipsilon + securitas for frontend
2020-06-03T12:44:45  <lcp> no, it runs SUSE accounts
2020-06-03T12:44:50  <darix> wtf is securitas?
2020-06-03T12:45:02  <lcp> an self-service frontend
2020-06-03T12:45:06  <darix> url?
2020-06-03T12:45:20  <Eighth_Doctor> https://github.com/fedora-infra/noggin
2020-06-03T12:45:23  <Eighth_Doctor> (it's called noggin now)
2020-06-03T12:45:27  <darix> ah
2020-06-03T12:45:32  <darix> see that name I knew :P
2020-06-03T12:45:36  <darix> stop confusing me
2020-06-03T12:45:38  <lcp> something that nicely replaces connect and self-service
2020-06-03T12:45:39  <lcp> killing more birds with one stone
2020-06-03T12:45:51  <darix> birds are important! dont kill them!
2020-06-03T12:45:59  <SteelShot> would someone be available to help with a user registration issue?
2020-06-03T12:46:01  <lcp> are they?
2020-06-03T12:46:05  <darix> yes
2020-06-03T12:46:15  <lcp> til
2020-06-03T12:46:15  <Eighth_Doctor> bees too :)
2020-06-03T12:46:24  <darix> SteelShot: which url are you using for registering and what issue do you see?
2020-06-03T12:46:30  <Eighth_Doctor> even though their stings do bad things to me :(
2020-06-03T12:46:30  <lcp> bees I knew
2020-06-03T12:46:32  <darix> Eighth_Doctor: bees are very underrated
2020-06-03T12:46:37  <lcp> birds seem pointless
2020-06-03T12:46:51  <darix> Eighth_Doctor: well dont make them sting you!
2020-06-03T12:46:58  <SteelShot> @darix, registration works, i just mispelled my email during it, me and my fat fingers
2020-06-03T12:47:21  <darix> I think that means you need to send an email to admin@opensuse.org
2020-06-03T13:00:20  <SteelShot> darix, sent an email. Thanks for the help
2020-06-03T13:53:16  <guillaume_g> Hi guys! openqa.opensuse.org is unreachable on port 80 anymore. Anything new on proxy maybe? Related ticket: https://progress.opensuse.org/issues/67684
2020-06-03T13:58:48  <lcp> kl_eisbaer: how is that? https://status.opensuse.org/
2020-06-03T14:25:54  <Martchus> lcp: The colors are much better. On e.g. https://status.opensuse.org/incidents/232 the paddings/margins look a bit odd.
2020-06-03T14:28:59  <lcp> Martchus: should be fixed now
2020-06-03T14:33:42  <Martchus> lcp: nice
2020-06-03T15:23:40  <kl_eisbaer1> lcp: looks like a wiki page ;-)
2020-06-03T15:26:01  <kl_eisbaer1> lcp: I like it. The only thing I'm not shure about (in general, so also for other pages) is the list of links to other pages we should provide. IMHO there should be a predefined set like www | wiki | forum | ... - and some special for each page. We should also discuss about the naming of those links. I - for example - would expect that "Issue Tracking" is pointing to bugzilla instead of progress. But that are details - and I'm no
2020-06-03T15:26:01  <kl_eisbaer1> t sure if we here are the right audience for it?
2020-06-03T15:27:40  <lcp> well, we don't do the standard set of links anymore because it sucked to not be able to crosslink related websites
2020-06-03T15:27:44  <lcp> so we do this instead
2020-06-03T15:28:11  <lcp> I will get our megamenu script to have the menu that links to other pages tho
2020-06-03T15:36:56  <kl_eisbaer1> lcp: just for the record: I am fine with providing even no link to other pages as I'm not using them anyway.  :-)   but maybe we can ask on opensuse-project@ for feedback? the people there have proven to discuss everything in detail ... ;-)
2020-06-03T15:38:00  <darix> https://www.golem.de/news/chat-server-matrix-experimentiert-mit-p2p-chat-im-browser-2006-148885.html
2020-06-03T15:43:23  <lcp> eh, yeah, it does show the limitation of matrix, and horrible architecture for p2p
2020-06-03T15:43:29  -heroes-bot- PROBLEM: DNS on nue-ns1.infra.opensuse.org - DNS CRITICAL - expected 195.135.221.140,2620:113:80c0:8::16 but got 195.135.221.140,2001:67c:2178:8::16 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=nue-ns1.infra.opensuse.org&service=DNS
2020-06-03T15:45:32  -heroes-bot- PROBLEM: DNS on freeipa.infra.opensuse.org - DNS CRITICAL - expected 195.135.221.140,2620:113:80c0:8::16 but got 195.135.221.140,2001:67c:2178:8::16 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=freeipa.infra.opensuse.org&service=DNS
2020-06-03T15:48:08  -heroes-bot- PROBLEM: DNS on chip.infra.opensuse.org - DNS CRITICAL - expected 195.135.221.140,2620:113:80c0:8::16 but got 195.135.221.140,2001:67c:2178:8::16 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=chip.infra.opensuse.org&service=DNS
2020-06-03T15:50:35  -heroes-bot- PROBLEM: DNS on nue-ns2.infra.opensuse.org - DNS CRITICAL - expected 195.135.221.140,2620:113:80c0:8::16 but got 195.135.221.140,2001:67c:2178:8::16 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=nue-ns2.infra.opensuse.org&service=DNS
2020-06-03T16:00:22  <lcp> I guess it's the result of the famous ipv6 rerolling, eh?
2020-06-03T16:02:15  * darix is unsure what the message should tell us
2020-06-03T16:04:28  <lcp> look at what heroes-bot complains about
2020-06-03T16:05:54  <darix> yes
2020-06-03T16:06:03  <darix> it could mention which hostnames it tests :)
2020-06-03T16:06:22  <darix> it is basically a mismatch of the ipv6 prefix
2020-06-03T16:06:38  <darix> I am not sure which is the one we should migrate to and which is the old one
2020-06-03T16:06:52  <darix> so in worst case the change is correct and just the monitoring needs an update
2020-06-03T16:13:15  <lcp> darix: it does mention, in the monitor url
2020-06-03T16:13:40  <lcp> nue-ns1.infra, freeipa.infra, chip.infra and nue-ns2.infra
2020-06-03T16:14:35  <darix> those are all the dns servers it queries
2020-06-03T16:14:46  <darix> but not which hostname it queries
2020-06-03T16:14:50  <lcp> good point
2020-06-03T16:14:56  <darix> any way ... later
2020-06-03T16:16:01  <lcp> cya
2020-06-03T16:37:34  <romulas> openqa login works now
2020-06-03T16:37:51  <romulas> you can update https://status.opensuse.org/
2020-06-03T17:19:53  -heroes-bot- PROBLEM: DNS on qsc-ns3.infra.opensuse.org - DNS CRITICAL - expected 195.135.221.140,2620:113:80c0:8::16 but got 195.135.221.140,2001:67c:2178:8::16 ; See https://monitor.opensuse.org/icinga/cgi-bin/extinfo.cgi?type=2&host=qsc-ns3.infra.opensuse.org&service=DNS
2020-06-03T18:11:25  <bmwiedemann1> cboltz: old openid provider is back. Message is dated 2020-06-03 17:56 so it seems, I won the race and we probably do not want to go back now.
2020-06-03T18:12:16  <cboltz> actually I'm surprised that it's back at all ;-)
2020-06-03T18:12:24  <cboltz> congratulations to winning the race!
2020-06-03T21:05:46  <romulas> Can't post an issue to: https://github.com/os-autoinst/openQA
2020-06-03T21:06:08  <romulas> Want to have a button for like "comments" but for "published".
2020-06-03T21:22:13  <cboltz> romulas: https://progress.opensuse.org/projects/openqav3 looks like a good place for your request
2020-06-03T21:28:17  <romulas> Done, thanks.