I'm not an Windows expert. But to my knowledge there are a couple of things missing here:

Yes the exact text from the announcement about the intermittent failures states:

I received email from google announcing the deprecation few days ago. In the announcement they stated that they'll introduce intermittent failures on responses from the G+ API as soon as 01/2019.

The original request focused on OTP, not U2F, but I think the amount of configuration required by OTP and the lack (?) of a pathway on mobile make it a better candidate for third-party integration than first-party integration. If we were supporting OTP in the upstream I'd want to run a first-party verification service so we aren't dependent on Yubikey's service, but the whole thing seems very messy and very bound to the Yubikey stack. It also looks (?) like Yubikey OTP and Yubikey U2F aren't linked to the same key (I think?) so you can't use U2F on one device and then fall back to OTP on mobile, even if you want to type in 44 characters? You have to enroll OTP and U2F separately.

This browser doesn’t support the FIDO U2F standard yet.

The bit-strength change above should still happen.

$table = new PhabricatorUser();
$cache_path = 'progress.json';

I just deleted the users above and am backing away from D19933, at least for now, since it doesn't feel like an especially great fit for either secure or admin.

On admin, basically every user with a blurb is abusive. I've just disabled the field as a coarse reaction.

I'm planning to banish these users from secure. This is mostly: polish (?) SEO bots; printer fax spam; and "security researchers":

There's some ephemeral data on this host and my house doesn't currently burn down if the associated services are unavailable, so I'm just going to let AWS restart it when the time comes.

Since the google-api is also disabled by default in Google Cloud env, I had to make changes to some other oauth provider at https://gitlab.com/SirEdvin/sanic-oauth/commit/fae23f6b35517dd9e8bec328dbb4dc883e033d78.
There, the g+ api was only used to get the user's email, iirc, and an alternative exists in https://www.googleapis.com/userinfo/v2/me.

• We still need to key the Image table in Pholio (see D19914) although the right key looks like just <mockPHID>.
• instances/ should get some cleanup for the changes to transactions.

Oh, this is on my personal AWS account. Oops!

I'll get this actually landed, but here's the patch I'm using for ForceUser until I get there:

I was also able to get OpenSSH 7.9p1 to build cleanly on OS X Mojave 10.14.2. For posterity:

(Please use Discourse for this sort of discussion.)

It's been several year's since this task has been opened up, and it's not clear what the current progress on this. Is there a way that versioning please be added to GitHub, per the recommendations on https://github.com/Homebrew/homebrew-php/pull/3864 ? I'm not able to install arcanist currently using homebrew because there isn't a stable tagged version newer than one from 2012.

@amckinley, for general context on where I'm headed here:

Notes for myself:

After the stack of changes under D19897 land:

This appears to be stable and working properly. D19897 removes a straggling guardrail.

Yeah, that's T10769.

In T13219#242865, @joshuaspence wrote:

I am seeing a similar issue on our install:

[2018-12-13 12:20:12] EXCEPTION: (PhabricatorClusterImproperWriteException) Unable to establish a write-mode connection (to application database "phabricator_repository") because Phabricator is in read-only mode. Whatever you are trying to do does not function correctly in read-only mode. at [<phabricator>/src/infrastructure/storage/lisk/PhabricatorLiskDAO.php:119] arcanist(head=stable, ref.master=d9a4293ae734, ref.stable=45a8d22c74a6), phabricator(head=stable, ref.master=2951694c2737, ref.stable=237a2a190984), phlab(head=master, ref.master=564c60d09ff4), phutil(head=stable, ref.master=dd136d1c3712, ref.stable=414a4c6abb1b)
  #0 PhabricatorLiskDAO::raiseImproperWrite(string) called at [<phabricator>/src/infrastructure/storage/lisk/PhabricatorLiskDAO.php:60]
  #1 PhabricatorLiskDAO::establishLiveConnection(string) called at [<phabricator>/src/infrastructre/storage/lisk/LiskDAO.php:1011]
  #2 LiskDAO::establishConnection(string) called at [<phabricator>/src/applications/repository/stora... (619 more bytes) ... at [<phutil>/src/future/exec/ExecFuture.php:380]
[13-Dec-2018 12:20:12 Etc/UTC] arcanist(head=stable, ref.master=d9a4293ae734, ref.stable=45a8d22c74a6), phabricator(head=stable, ref.master=2951694c2737, ref.stable=237a2a190984), phlab(head=master, ref.master=564c60d09ff4), phutil(head=stable, ref.master=dd136d1c3712, ref.stable=414a4c6abb1b)
[13-Dec-2018 12:20:12 Etc/UTC]   #0 <#3> ExecFuture::resolvex() called at [<phabricator>/src/applications/repository/daemon/PhabricatorRepositoryPullLocalDaemon.php:446]
[13-Dec-2018 12:20:12 Etc/UTC]   #1 phlog(PhutilProxyException) called at [<phabricator>/src/applications/repository/daemon/PhabricatorRepositoryPullLocalDaemon.php:453]
[13-Dec-2018 12:20:12 Etc/UTC]   #2 PhabricatorRepositoryPullLocalDaemon::resolveUpdateFuture(PhabricatorRepository, ExecFuture, integer) called at [<phabricator>/src/applications/repository/daemon/PhabricatorRepositoryPullLocalDaemon.php:222]
[13-Dec-2018 12:20:12 Etc/UTC]   #3 PhabricatorRepositoryPullLocalDaemon::run() called at [<phutil>/src/daemon/PhutilDaemon.php:219]
[13-Dec-2018 12:20:12 Etc/UTC]   #4 PhutilDaemon::execute() called at [<phutil>/scripts/daemon/exec/exec_daemon.php:131]

I am seeing a similar issue on our install:

One piece of minor mess here -- when you bin/auth recover yourself into a MFA'd account, you can get two MFA prompts: one to upgrade the session, then one to allow you to perform a password reset. Probably, the contextless password reset should only require MFA if you actually submit the form, and should do one-shot MFA, and ideally should carry the challenge tokens from the login and belong to the same workflow, although that's probably impractical.

Bind Challenges to Sessions

If you want me to look at something, file a report on Discourse with reproduction steps that I can follow to reproduce the issue. I don't need any other discussion or context. I do need working reproduction steps.

No.

@epriestley I have seen you working on Mercurial stuff. Can you take a look at my findings above?

Sorry, yeah, I meant T6703.

I believe that instead of T7667 you meant to write T6703.