Former Wikimedia Trust & Safety, Current Volunteer!
Professionally moving to Twitter as Manager, Safety Operations (Live Video)
@Jalexander done! There is now a directory on stat1007 (stat1005 is deprecated) called jamesur in foks's home directory (owned by `foks:root and read/write/execute only for him). Is there anything else that you want to keep? Is the Hive db important?
Stuff to delete in both users
- home dir in stat1005
- home dir in hdfs
- database jamesur in hive (1 table)
Are you running it with mwscript extensions/SecurePoll/cli/dump.php --wiki=foowiki --options?
This seems to be a chronic problem at least with SecurePoll scripts, most of them have some variation of an empty option. makeSimpleList.php gave me problems earlier because I needed to use one and so instead I had to copy it to my home directory and edit it (basically adding it as an option with an argument/not empty) and then I could get it to work. Not sure if this is an issue with mwscript or internal ways with how maintenance scripts are checked but it wasn't this was at least last year. We were able to find workarounds for this election but had to include manually inserting the key into the DB etc so would be good to either update the scripts or figure out what's up with the wrappers.
Let's clean it up all at once and also do something with pat@ what about box6699@ in general. and what about the OTRS queue "archive01". Added Legal.282 ## Legal ## 283 legal-en: legal 284 pat: box6699 285 gary: box6699 286 box6699: mdennis, archive01 287 gc: legal 288 legalquestions: legal, liaison
FTR this is fixed if I force the system to PHP7 via x-Wikimedia-Debug
FTR this is fixed if I force the system to PHP7 via x-Wikimedia-Debug
As an aside, telling x-wikimedia-debug to send me to a php7 seemed to make it work, so definitely seems hhvm related.
Not sure if this is enough but what I was seeing in logstash. I have a feeling there are other log issues that aren't appear in there (at least with my current search)
If a user needs to be blocked, does it really merit the amount of trust that is needed for holding the CheckUser privilege?
FTR I'm ok with this I think I mentioned it @Varnent earlier and he didn't have an issue but I will ask again tonight :)
FYI the "old" method of using eval.php ( see https://wikitech.wikimedia.org/wiki/Password_reset ) is also not working. Right now it seems like the only option is directly editing the centralauth database. Weirdly running the script/using eval.php DOES change the authentication date on the central database just doesn't change the email address.
@PEarleyWMF: we discussed privacy implications; can you comment further on this, and if/who you think should be looped in.
Just for documentation purposes on here because I know some task readers were confused (others are not, it's just not clear in the writing :) ): Global blocks are IP based instead of user based so there are no "globally blocked users" in this case. This particular bug comes up when someone is editing on an (unblocked) local account but connecting via a globally blocked IP that is "hard" blocked (does not allow editing even when logged in unless you have the ip block exemption user right). Still should be fixed (and Roan and I chatted so i know he was fixing it with this in mind) just clarifying for the audience :).
Please note this task is currently blocked on @PEarleyWMF logging into their wikitech account to create the ldap entry (which is automatic upon their login.)
Until that time, this is unable to proceed.
Please note that I'm now on clinic duty this week, so I need to confirm a few things. This task is currently blocked by @Kbrown logging into their wikitech account. Once they do so, we'll be able to check if the ldap user was created and can move from there.
(Granted I obviously can't do that now for them when the account is already created... though I guess I could try to rename it away)
Did she log into wikitech and set a real password instead of the temporary one? That would populate user_password.
Yes-ish. I logged in and tried to set a real password, but got an error message (the exact content of which I have unfortunately forgotten, but I think it was something about the "authorization plugin"?), and now can't log in with either original temporary password OR the new password I tried to use.
Hi @PEarleyWMF @Jalexander Could you please create a user on Wikitech/LDAP (https://wikitech.wikimedia.org/w/index.php?title=Special:CreateAccount&returnto=Main+Page) and let us know which user name you picked?
See related security issue T179900 (which we've seen at least a couple independent complaints about so can be found)
Pinging this because it's come up in a review of some of our privacy questions, it would be really good to try and find a way to resolve this. For me it's mostly the email question. A user who is removing or changing their email can understandably assume that they are removing the old version from our record and we tend to tell people this. Unfortunately this issue means that not only do they not realize that the email continues to exist elsewhere the ability to remove it is now out of their hands. If they go to another wiki and look at their preferences (for example) it will still say they don't have an email address set because the preferences are checking the global database.
This is done now, @Alhen please let us know if you run into any issues.
I tried, but I have been unsuccessful so far, hence this request. I must have made a mistake when writing them down or something.
Hi there, So the browser login that was still working no longer works -- and I am no longer able to edit Wikipedia logged in a BrillLyle. Please, if anyone can help, I would really appreciate it. I would prefer not to have to register a new account. Thanks so much in advance. - Erika aka BrillLyle
FWIW it would be ideal if the tool still used UTC since all dates / times from the sites use UTC. Trying to mentally work that out into local time would be very confusing :)
This task is under UBN status for nearly one month, is there any reason that without fixing this task, tool can't work well? If not, I would suggest to downgrade UBN to High or Normal.
Since the crack started, the CAPTCHA error rate was high.
However, at about 5/3 18:30 UTC, the CAPTCHA error rate suddenly falls (from almost 100% to a normal rate).
Guess: the cracker find a way to bypass the CAPTCHA check (e.g. proxies, fake IP's).
The reduction there is because of other mitigation techniques (not a bad thing)
FTR (said in a call with the Stewards Tuesday but for the record) I'm going to be talking with Legal about this and will loop back once we're set there and/or have other questions.
Assigning High so that it's first looked at if we have time for it since it makes the CP tool unusable (they are basically always deleted/suppressed already).
There are a few permission that should still be added to Ombudsman group , so they can see everything correctly. It was reported that one of them can't see the details of a log.
I would add:
I could add if none opposes that.
 - https://meta.wikimedia.org/wiki/Special:GlobalGroupPermissions/ombudsman
These permission above are only for viewing and are already available to stewards.
I get "Originating IP address Not Available" on Wikispecies, when trying to use this function, and it doesnt come up in the Check user log.
This is approved from the Trust & Safety side now (and hence the WMF). @MarcoAurelio is doing the global changes now and submitting the local patch which I'll shepherd though SWAT this afternoon.
We're pretty much good, done a bit of testing and will do a bit more but should be ready to roll out a patch to give to CUs on Tuesday (US Holiday on Monday and I'd rather not launch with folks either on their weekend or going to it in case there are issues/questions).
Grabbed this because in addition to walking through it with Aeryn tomorrow going to do some production testing from the SuSa side. Once we're all set I'll submit the patch to turn on for CUs etc. (assuming the old data purge stuff is set up? I believe that is now but will check on).
@MarcoAurelio In my local wiki on a VM, I tested this code every time I submitted a new patch and it did log the data appropriately. I have no way to tell if there is a beta limitation involved or not. Do you think I could be temporarily given access to beta to test things out there?
The patch looks good from SuSa's side. We'll also want to add it to a couple global groups but I've verified it's available and we do that on-wiki so I'll send a note to the Stewards to do that side.
done :) thanks RadiX
Thanks Marco, done. Verified with CUWiki
FTR this can get held off for now (or even just closed as rejected). We're transitioning away from Mailman for this list. Handling the archives that currently remain will be decided after.
Thanks David, still got this though the file upload is definitely working now. For the error I'm filling in the the form for DMCA completely and so far have tried either not uploading a file, not sending to Lumen and Not posting to WMF Wiki and still getting the error (though the exact error adjusts since some things are no longer saved in the query). For simplicity writing down exactly what I'm using in case there is any weirdness that's causing it:
@Jalexander: the workaround is to suppress the log event manually, no? Doesn't seem worth keeping private accordingly unless I am misunderstanding...
Pulling this in to the security zone because the attack vector it exposes.
Still need on my end preferably without expiration. Biggest use is hive/beeline access for relatively routine subpoena/legal data gathering (one might need to happen today for example depending on what we decide at a meeting) and occasionally other T&S investigations when needed and approved (rare given the level of private data but important when needed).
The mailman UI supports this via the configuration variable header_filter_rules aka. 'Spam Filter Regexp' (description: Filter rules to match against the headers of a message.). See also https://www.gnu.org/software/mailman/mailman-admin/sender-filters.html
This can be found in the administrative interface in Privacy options...-> [Spam filters] -> Spam Filter Regexp (or visit directly the URL, replacing YOURLIST with your list name: https://lists.wikimedia.org/mailman/admin/YOURLIST/?VARHELP=privacy/spam/header_filter_rules ).
So someone from Operations has to check Spam Filter Regexp for each list ? Write a small script ?
This is going to be slightly stalled for a short time, the salesforce instance is still having it's final setup because we've been transferring over all of our data from Sugar. It should be done and available to be dealt with later this week. I'll see if I can scrounge up documentation to help in the meanwhile too :)
@kaldari do you know if this is possible atm?
@jrbs There's a script in MediaWiki core that allows resetting email and password for an account. If the problem is that you cannot be convinced by the evidence of the edit linked here that this account belongs to the requestor then I have no objections but if it is for technical restrictions then please have a look at resetUserEmail.php and changePassword.php.
Welp! doesn't need OAuth. https://meta.wikimedia.org/w/api.php?action=sitematrix&format=json
So I did this, and then noticed it was assigned to @Jalexander, my apologies if I shouldnt have processed this! (I normally would leave assigned tasks alone, I was just working on mailing list items and got carried away.)
Please note this list has now been created: https://lists.wikimedia.org/mailman/listinfo/wikiwomencamp. Please note the list description should be set more accurately by the list administrators.
The initial list admin password is only sent to the original list owner (kharold), not to everyone on the list. Additionally, the list is set to most permissive first, since it wasn't requested otherwise. So archives and list is public, but the list admins can lock that down easily enough.
Alright, fair enough. :) Thanks for the info. I'm just now having to clean up after a cloned banner so I might be a little jaded ;)
Assuming we don't want to change that workflow, it probably means that we don't want to host the tool on Tool Labs. According to Bryan, its best to believe that anything in Tools can be seen by anyone else. There are only a small number of people with root access, but lots and lots of people have shell access and local root exploits are possible.
... upload the offending image to the tool and it sends it to the National Center for Missing and Exploited Children
@Jalexander: Do you know if the images are stored locally to the file system (even temporarily)? If so, using Tool Labs might be risky.
Yeah, the OAuth info should not be an issue. That is all handled securely. I'm not sure I understand what James is saying about "offending images are uploaded/processed and sent externally for example and IP data is processed". @Jalexander, could you elaborate on that? When you say that images are uploaded/processed, where is that occurring? Are you uploading copies of the images into the tool itself? Or just referring to the copies on Commons? What do you mean by "sent externally"? Does the tool email a copy of the images to law enforcement? If so, we would need to double check who has access to the Tool Labs email server, but I don't imagine it would be a blocker. Mostly, we're worried about the tool storing its own copy of private/sensitive data. If that isn't happening, it's probably OK to host on Tool Labs.
Meta is currently under script error. The error is Uncaught Error: Unknown dependency: mw.geoIP
These both seem to be working now, not sure exactly what happened but I'm at least a bit nervous that it was me a couple hours ago :( ( in an attempt to fix some issues with a gadget I tried to set a dependency to solve a race condition https://meta.wikimedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=16752348&oldid=16751393 ). Still don't think it "should" have caused everything else to fail but wouldn't be the most surprising thing.