Already discussed as part of #34, let's create a separate ticket for this.
We currently have an admin interface, but we require no authentication. Anyone can do anything. That is of course bad, and we need to change it.
On the other hand, Sumantro points out that a forced authentication will make it harder for test day owners to update it, which is true. We should take that into consideration, perhaps there are ways to account for this (as an immediate idea, e.g. generating a url that would allow anyone opening it to edit one particular event).
Good idea, thanks!
Yes. One thing comes to my mind here, if we wouldn't want to clobber testdays with oidc implementation (which is always pita on its own), we might be able to work with infra team to disallow anonymous wiki edits for everything outside of testing matrices? That way, auth would be handled for us for free!
On the other hand, Sumantro points out that a forced authentication will make it harder for test day owners to update it, which is true.
I have an issue with this point of view. Having FAS is just the standard for anybody to do anything in Fedora. Be it updates to packages, new packages, giving karma to updates, ... One path here would be to also accept RH kerberos for auh, but I have no experience with integrating this.
(as an immediate idea, e.g. generating a url that would allow anyone opening it to edit one particular event).
This is more Security through obscurity than proper security if I am to be honest...
we might be able to work with infra team to disallow anonymous wiki edits for everything outside of testing matrices
That's basically already in place, the only exceptions are release validation pages and test day pages, I think. We could remove the exception for test day pages, but that would preclude test day owners without FAS to edit the wiki, and it would also preclude testers without FAS to submit results, if wiki is used instead of testdays app. (We still support this option, as a fallback if testdays is broken or if the test day owner simply prefers using wiki directly).
So I'm not sure if we really want to do this. But even if we did it, it would still allow any Fedora user to edit anything regarding testdays, and that's probably not what we want? I assumed the testdays would probably require the user to be in the qa or qa-admin FAS group or similar.
qa
qa-admin
Having FAS is just the standard for anybody to do anything in Fedora.
We can definitely re-discuss this, but historically, we wanted to avoid requiring FAS, especially for user submissions. Otherwise we would get fewer test results. For test day owners, I assume there might be parties who can be interested in running a test day but don't have a FAS account (e.g. a LibreOffice devs would have a LibreOffice test day in Fedora), but I'm not sure how common this is, Sumantro can possibly tell us. And in this case it might make sense to require FAS, perhaps. But it still clashes with the "wiki-as-a-fallback-for-results" approach, because you can't separate test day owners and testers in this case.
It's a pretty standard approach in many modern online services (if you upload a file to a file hosting server, you get a secret url, if you organize something like WhenIsGood, you get a secret url, sharing a file publicly from your Google Drive gets you a special url, etc), I think it's fine for this use case. I'm not saying it's the best approach, it's just something that occurred to me.
we might be able to work with infra team to disallow anonymous wiki edits for everything outside of testing matrices That's basically already in place, the only exceptions are release validation pages and test day pages, I think. We could remove the exception for test day pages, but that would preclude test day owners without FAS to edit the wiki, and it would also preclude testers without FAS to submit results, if wiki is used instead of testdays app. (We still support this option, as a fallback if testdays is broken or if the test day owner simply prefers using wiki directly). So I'm not sure if we really want to do this. But even if we did it, it would still allow any Fedora user to edit anything regarding testdays, and that's probably not what we want? I assumed the testdays would probably require the user to be in the qa or qa-admin FAS group or similar. Having FAS is just the standard for anybody to do anything in Fedora. We can definitely re-discuss this, but historically, we wanted to avoid requiring FAS, especially for user submissions. Otherwise we would get fewer test results. For test day owners, I assume there might be parties who can be interested in running a test day but don't have a FAS account (e.g. a LibreOffice devs would have a LibreOffice test day in Fedora), but I'm not sure how common this is, Sumantro can possibly tell us. And in this case it might make sense to require FAS, perhaps. But it still clashes with the "wiki-as-a-fallback-for-results" approach, because you can't separate test day owners and testers in this case.
I side with Kamil. Test Day is the most non-friction and easy barrier of entry for us. This is what I usually call the "drive by contributors". The people who would read a magazine post or community blog and just update the results page for us at the EOD. The test day owners in recent future will be folks from upstream (podman might wanna run a test day which is tracked in their system and they use test days app to gather the data from contributors). The owners in most of cases should not require FAS. I onboard a bunch of kids from join and I can tell you, in every 10 in 50 get a spam account check prevention which needs to be dealt out with infra and worst, even when everything goes right, many a times, FAS just wont log in. I have previously spent hours telling people to use their personal email ID with hyperkitty for ML because OAuth with FAS was PITA.
This is more Security through obscurity than proper security if I am to be honest... It's a pretty standard approach in many modern online services (if you upload a file to a file hosting server, you get a secret url, if you organize something like WhenIsGood, you get a secret url, sharing a file publicly from your Google Drive gets you a special url, etc), I think it's fine for this use case. I'm not saying it's the best approach, it's just something that occurred to me.
(Please, let's limit the amount of quoted text so that these tickets get easier to read, thanks).
Login to comment on this ticket.