User Details
- User Since
- Oct 6 2014, 7:38 PM (527 w, 1 d)
- Roles
- Disabled
- IRC Nick
- csteipp
- LDAP User
- CSteipp
- MediaWiki User
- Unknown
Jan 24 2023
Jan 5 2020
Feb 8 2019
Oct 1 2018
Sep 16 2016
Jun 29 2016
have php-openssl, but it does not support aes-256-ctr mode
Jun 15 2016
I think the fewer places we have the password the better. So I think this is fine.
Jun 6 2016
It seems like this is again overlapping with the discussion on T130748. We
were discussing there a cookie that the user could opt into, and then the
server wouldn't send the strict headers.
May 27 2016
A C-level needs to approve. That would be @Wwes .
Is L2 still the correct agreement to sign?
Yes
@dpatrick, sounds good
https://gerrit.wikimedia.org/r/#/c/289778/ with https://gerrit.wikimedia.org/r/#/c/289780/ fixes this particular case. I'll see if I can get those merged today.
May 26 2016
The only thing that makes me sad about this is that it would mean that wikitech remains an LDAPAuth wiki indefinitely blocking my desire to convert it to part of the normal SUL wiki family when we have all of the OpenStack features migrated to Horizon or other related systems. (And yes I know that LDAP is used for more than OpenStack.) I would personally be more excited about consolidating the validation in https://www.linotp.org or something similar.
If you want to use ldap to store the secret, then mediawiki's Ex:OATHAuth needs to be ldap aware (or have hooks to let another extension swap out the secret). It's ugly, but doable.
@dpatrick, are you the ios version of Google Authenticator, right? It's working fine for me as is, on android. But using the updated javascript also works, so probably good to get that rolled out.
May 25 2016
On labswiki, the user table was create at a time when the collation wasn't explicitly set, so it's
Ah, I see.
@aaron, is there a way to see the actual request causing this? It must be for Special:OATH, but more details would be helpful.
May 24 2016
If you decide to go with the crypto cookie, I'd recommend using a JWT, with either an HS256 or ES256 signature. It's url-safe encoded so unlikely to get corrupted, and there are plenty of libraries out there so you don't have to try and get it right yourself.
May 20 2016
Thanks for fixing Max. I'll let Yurik or someone more familiar with the code review the patch.
May 19 2016
May 18 2016
OATH has been rolled out to testwiki and test2wiki. Everything seems to be working as expected. Assuming no issues come up, I'll make it available on all wikis (to Staff global group only) tomorrow in SWAT.
mysql:wikiadmin@db1041 [centralauth]> CREATE TABLE `oathauth_users` (
-> `id` int(11) NOT NULL,
-> `secret` varbinary(255) DEFAULT NULL,
-> `scratch_tokens` varbinary(511) DEFAULT NULL,
-> PRIMARY KEY (`id`)
-> ) ENGINE=InnoDB DEFAULT CHARSET=binary;
Query OK, 0 rows affected (0.06 sec)And after the SpecialUserlogin refactor with wmf2, had to patch LoginSignupSpecialPage.
May 17 2016
@Tobi_WMDE_SW, we'll try to work it in, but since we didn't schedule it at the beginning of the quarter, we have a lot of other reviews already scheduled-- we're fully booked between now and the end of the quarter. So unless an anticipated project isn't ready for review, it will likely be at the beginning of July.
Reopening. I'll get the updated portion of the patch deployed.
May 16 2016
Pictures from our initial whiteboarding of the service, and some considerations for building it.
Yep, here's my patch:
May 12 2016
Implementation using mwoauth looks good. It uses defaults for nearly all processing, which should be safe. It correctly uses the identify method to get the user's identity.
@jcrespo, it's on S7, centralauth database. The table will be 'oathauth_users'.
I've scheduled time on May 18th to create the table, and enable the extension (only accessible to a few people).
May 11 2016
Deployed by @MaxSem,
May 10 2016
Both Brian and I looked at the patch, and it seemed like it should fix the immediate problem. Max is going to deploy it.
csteipp added a blocking task: T134863: Reflected XSS in GlobalGroupPermissions.
Cool. At .5 kloc of php, should be a quick review.
15:52 csteipp: deployed patch for T134863
Thanks @Grunny! I'll get that deployed as soon as our normal deploy window is finished.
May 9 2016
This would add Yubi OTP to phabricator as a second factor (from skimming the code, if I'm missing something else, let me know).
Thanks for the update. I've tentatively rescheduled for the week of May 30th. Let me know if it looks like it won't be ready by then.
May 5 2016
Darian has them written up, and I think he'll be passing them on today or tomorrow
We can potentially avoid session inflation by creating the session separately from creating the edit html (which would indeed allow session inflation if an attacker requests edit urls repeatedly without cookies enabled). For example, we could start the session from JavaScript on the edit page in a background request (AJAX).
Was this made a security issue on purpose? I noticed the order of the "Create Task" dropdown in Phab changed yesterday, so I'm wondering if this was by accident...
Line $username = User::getCanonicalName( $username, 'usable' ) ?: $username; should be backported.
I'll do the backports of T132874 today or tomorrow
19:30 csteipp: deployed patch for T132874
@Jdforrester-WMF is this at the point where you want a review now?
@dpatrick / @Bawolff / @MaxSem - All those patches are deployed now. Can you all make sure you have 'SECURITY: ' at the start of the commit summary? Makes it easier to see on the cluster what's been added on top of master when deploying, and probably good to be consistent when we push these into master.
18:47 csteipp: deployed patch for T133507
New version based on csteipp's CR:
T133507-master
Redeployed core patch (with define), and dependent Math patch.
Patch is now deployed.