You might have to stop the gridengine webservice from the old bastion (login-trusty.tools.wmflabs.org).

Installing Pillow via pip did work for me however after updating pip itself to a newer version that supports wheels:

Sure, that sounds fine by me.

rc_id is still signed as far as I can tell – at least, it’s not explicitly unsigned in the documentation, in maintenance/tables.sql, on the replicas, or on mwdebug1002. Or am I misunderstanding something? (I’m not very familiar with (My)SQL, sorry, but as far as I can tell from a quick Google, signed is the default.)

For what it’s worth, on enwiki the rc_id has now crossed the halfway point (assuming it stays signed):

Okay, building the venv from the Trusty bastion doesn’t work because the python3-venv apt package is apparently not installed, and building the venv from the Stretch bastion is useless because it’ll install Python 3.5 packages that won’t be found by the tool running under Python 3.4 on the Kubernetes hosts.

If the tool will be running on the Kubernetes backend, I assume you’d want to reinstall the npm dependencies from inside a webservice --backend=kubernetes nodejs shell and not on the bastion directly.

Requesting a Gerrit repo is just a matter of asking at https://www.mediawiki.org/wiki/Gerrit/New_repositories/Requests. QChris and myself handle most of them in due time

As a tool author, I can confirm that the only reason I use Diffusion for hosting my tools’ source code and recommend it to others in cookiecutter-toolforge is how Striker makes it completely frictionless to create new repositories. On the other hand, personally I intensely dislike Differential for contributions both as a patch author and as a tool maintainer, and recently decided to mirror my tools to GitHub as well. If Striker was changed to create open-push Gerrit repositories instead of Diffusion repositories (well, I suppose at least for a while it would have to be “in addition to”, not “instead of”, to ease the transition?), I would gladly migrate to that.

A few days later, five requests slower than two seconds but none slower than five seconds:

Hm, no requests slower than two seconds today…

Alright, just to be sure, I rebuilt the venv.

I think I built the venv from inside a Kubernetes shell, but I’m not quite sure. I could always rebuild it just to be sure…

Yep, that’s the same case (thanks for adding me as a subscriber). Good to know that this issue isn’t “lowest” priority because the ramifications were unknown, but rather in spite of them being known for years…

Splitting edit and change sounds like a good idea to me, but doesn’t seem likely to happen soon :)

May I suggest that the priority of this task be increased somewhat? Without going into too much detail – until this task is fixed, no Toolforge tool can fully protect itself against attacks from other tools. (Sufficiently privileged users can see e. g. T211424 for some more details on possible attacks, though I doubt it’s the only relevant task.)