It seems the commit didn't fully fix the issue. When pygmentize runs for phabricator, there are processed that are forked from the initial process that are still never killed and they cause the cpu to spike. For example, when running into this issue on our install, we see something like:
#ps aux | grep pygm
user 13190 0.0 0.0 4456 680 ? S 16:46 0:00 sh -c pygmentize -O encoding=utf-8 -O stripnl=False -f html -l 'bash'
user 13191 0.0 0.0 4456 784 ? S 16:46 0:00 sh -c pygmentize -O encoding=utf-8 -O stripnl=False -f html -l 'bash'
user 13192 74.7 0.0 23996 9336 ? R 16:46 0:05 /usr/bin/python /usr/local/bin/pygmentize -O encoding=utf-8 -O stripnl=False -f html -l bash
user 13193 76.7 0.0 23636 9028 ? R 16:46 0:06 /usr/bin/python /usr/local/bin/pygmentize -O encoding=utf-8 -O stripnl=False -f html -l bash

PHI979 is a specific issue where we could use better instance controls (around worker count) in the short term. An alternative approach is to hard-coded if ($instance === 'X') { ... } for now. admin could also probably use more workers, I think we get saturated by backups occasionally.

Yeah, I think the issue is:

The "keep the profiler on across form submissions" code isn't working on secure.phabricator.com, even though it works locally and __profile__=page appears on the "Request" tab.

• PHI979 describes a case where we'd like to automatically increase the worker task limit based on instance size. admin should also get an increased limit.
• Now that MFA can be disabled completely, I want to disable MFA on admin (pretty much everyone adding it is adding it by accident) by deprecating the provider.
• T13178 is adjacent to a lot of this.

Continued in T13242.

After T13222, this is more relevant:

From T13222, MFA on related flows should generally be updated.

From T13222, this should also revisit MFA around Conduit tokens. In particular:

"Kick everyone down to partial session" docs / tooling.

For now, I'm continuing to allow users to "Remove" the last active factor on their account when security.require-multi-factor-auth is enabled. This will kick them to the MFA enrollment screen.

I think I have this working fairly reasonably, now. There are four major cases:

In T13231#243710, @epriestley wrote:

Another issue here is that Duo doesn't seem to have a way to prevent new user creation. YIf you /preauth a user, they get an enroll link whether they already have an account in Duo or not, and there's no apparent way to distinguish between "this creates a new user" and "this encourages an existing user, who has already been created but has not enrolled a device yet, to enroll".

Another issue is that we apparently (???) only get one shot at learning the user's (internal-to-Duo) User ID, and only if we're allowed to enroll them. The first call to /enroll gives us a user ID, subsequent calls do not and there's no other way to do the lookup. This isn't really a problem, it just means we're forced to use usernames everywhere (which are mutable/aliasable/etc/etc) when we could otherwise use nice stable user IDs.

Another issue here is that Duo doesn't seem to have a way to prevent new user creation. If you /preauth a user, they get an enroll link whether they already have an account in Duo or not, and there's no apparent way to distinguish between "this creates a new user" and "this encourages an existing user, who has already been created but has not enrolled a device yet, to enroll".

Thanks, that's quite helpful!

If we want to synchronize to existing accounts, I think it's not good enough for us to pick the user's email address unless that's also the username the organization already uses -- in your case, is it?

I'm imaging that one use case is that you just want everyone to use MFA, and Duo is a more attractive approach than TOTP (since it's easier to use) or SMS (since it's more secure). In this case, you might just be using Duo as "Better TOTP", and the enrollment/management side isn't as important. For example, if we deployed Duo on secure or in the Phacility cluster as a default option, we'd use it in this mode.

FWIW - most users of this feature (especially after T13229) will be organizations that already have DUO in their environment, and likely already have users defined in DUO. Creating random usernames, or PHID's is probably not going to work for most of those organizations. Phabricator does require email's to be unique (no reuse) so that might be a better choice for initial userid setting?

When you delete a Duo factor from your phone app, you still get prompted to "auth", Duo just reports that you have no enrolled devices which support push.

Not exactly related, but PEAR got compromised: https://news.ycombinator.com/item?id=18987518

Striping should probably "revoke" (disable + can not be re-enabled), vs the user "remove" button becoming a "disable" action.

Duo wants us to <img src="..." /> a QR code.

With a 15-second TTL, the user doesn't vanish or anything, and Duo does not let us do another enroll attempt even after the enroll time expires:

If you try to /enroll the same user PHID twice, the second /enroll fails:

Rolling this mess up again:

I think this is more or less at the end of the line in terms of actionable work that doesn't make more sense being scoped in elsewhere.

This will probably roll forward into a "next iteration", but it would be nice-to-have to show users the numbers we expect to text them from, so they can whitelist/anticipate the messages.

managing contact numbers

Also, managing contact numbers needs to require MFA or evading SMS MFA is trivial. 🐈

Currently, I think attackers can CSRF the MFA enroll endpoint (/mfa/new/?provider=xyz). This could send you an SMS, soon. This is mostly harmless but potentially a little annoying with push factors like SMS/Duo. I'll get a CSRF gate on it.

Also, I think we still have an issue with rate limiting where:

So I don't forget about it: the default settings/ UI is now incorrectly showing Conpherence settings, not date and time settings. Clicking anything works properly.

The need for more UI support on the "MFA Required" flow is making me consider expanding scope here into knocking "Settings" back out to a full-width UI. I think that's not terribly hard. I'm maybe going to start there so it can get more testing as I go through everything else, and I can give up if it's harder than I think.

From D19975, two considerations:

T13227 also needs to happen this week.

Thanks! I get the same behavior locally, I filed this upstream: https://bugs.php.net/bug.php?id=77496

I can't get MYSQLI_OPT_LOCAL_INFILE to work on secure, either. I tried on secure001 and secure004 (where the database is not local). As far as I can tell, this option doesn't do anything, anywhere, ever?

I believe D19969 has now fixed this, although I'm not entirely certain, since it was never reliably reproducible in production so there's no way to really test or verify it.

We're probably done here, but ideally the next steps are:

Reproduction steps are: