In T212127#4836777, @elukey wrote:

@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?

Thanks :)

In T212127#4831160, @fdans wrote:

Stuff to delete in both users

jamesur:

• home dir in stat1005
• home dir in hdfs
• database jamesur in hive (1 table)

In T212027#4825469, @Reedy wrote:

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.

In T210464#4776173, @Dzahn wrote:

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

moving to security given attack vector possibilites

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

In T209802#4756957, @Bawolff wrote:

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)

In T208512#4713120, @Platonides wrote:

If a user needs to be blocked, does it really merit the amount of trust that is needed for holding the CheckUser privilege?

In T208035#4697364, @Rxy wrote:

In T208035#4697333, @Krenair wrote:

I suppose the reason that the userrights right can't also go is local custom groups that don't appear on meta?

yeah, We need sometimes local userrights right for that reason.

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.

In T200559#4505772, @Iislucas wrote:

@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 :).

In T104729#4077128, @jrbs wrote:

What's the status of this now there's the new takedown tool?

In T201667#4516460, @RobH wrote:

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.

In T201668#4516444, @RobH wrote:

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)

In T201668#4503699, @Kbrown wrote:

In T201668#4503579, @Legoktm wrote:

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.

In T201668#4500160, @Dzahn wrote:

Note that "kbrown" is a username already taken in LDAP and it's KEVIN Brown, not Karen.

@Jalexander @Kbrown Could you please make a Wikitech/LDAP user (on https://wikitech.wikimedia.org) and let us know which one you picked?

In T201667#4500192, @Dzahn wrote:

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.

In T199231#4413606, @Alhen wrote:

I tried, but I have been unsuccessful so far, hence this request. I must have made a mistake when writing them down or something.

In T198536#4394666, @BrillLyle wrote:

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

In T197836#4305869, @jrbs wrote:

In T197836#4305783, @dbarratt wrote:

In T197836#4305705, @jrbs wrote:

Is the back end using UTC, maybe? If you were doing this after 00:00 UTC it might be confused. Just a hypothesis.

I think you're on to something. :)

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 :)

In T197837#4304262, @TBolliger wrote:

James, can you please set an appropriate priority for this and T197838 and T197836? Our SLA will be:
— UBN interrupts the current sprint
— High gets taken into our next sprint
— Normal (and lower) are ignored until a future focused improvement sprint

In T181570#4132686, @Liuxinyu970226 wrote:

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.

@dbarratt ^^

In T193769#4180966, @EtaoinWu wrote:

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).

In T160357#3992683, @Teles wrote:

There are a few permission that should still be added to Ombudsman group [1], so they can see everything correctly. It was reported that one of them can't see the details of a log.

I would add:

• abusefilter-hidden-log
• abusefilter-log
• abusefilter-log-detail
• abusefilter-log-private

I could add if none opposes that.

[1] - https://meta.wikimedia.org/wiki/Special:GlobalGroupPermissions/ombudsman
These permission above are only for viewing and are already available to stewards.

In T160357#3988173, @Dan_Koehl wrote:

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).

In T152934#3954489, @Huji wrote:

@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?

In T152934#3954491, @MarcoAurelio wrote:

@Huji I'm sure we can arrange that if @Jalexander is okay :)

Done

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.

In T173475#3566945, @Niharika wrote:

In T173475#3566752, @dbarratt wrote:

T173475-6.patch6 KBDownload

Why is this not on gerrit...?

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:

In T171430#3475355, @dpatrick wrote:

Hi all. @Jalexander, @Kbrown can you confirm than Karen has completed either an employee or volunteer NDA?

In T171405#3464081, @lfaraone wrote:

@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).

In T170601#3437121, @Framawiki wrote:

From https://wikitech.wikimedia.org/wiki/Mailman

Spam scores

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 SRE 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?

In T167982#3370106, @MarcoAurelio wrote:

@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.
Regards.

In T166400#3335406, @dbarratt wrote:

Welp! doesn't need OAuth. https://meta.wikimedia.org/w/api.php?action=sitematrix&format=json

Honestly I think this should be rewritten as a SPA in JavaScript. :)

In T167059#3316216, @RobH wrote:

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.

In T46481#3306927, @jrbs wrote:

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 ;)

In T159898#3290732, @kaldari wrote:

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.

In T159898#3290565, @kaldari wrote:

... 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.