See a note in T12509 about HMAC key regeneration.

For the record: I'd like us to get away from maintaining our own phab fork, and I agree that means probably migrating to a different system at some point.

FWIW, I think describing these as "non mainstream" and the entire description of these communities sounds to me ... somewhere between biased and pejorative. Makes it hard for me to keep engaging in the discussion.

Does anyone have experience with an existing Push Notifications As A Service provider? I would naively suggest AWS SNS, because we already depend on other AWS services and it's free for the first 1m pushes, and then $0.50/1m pushes after that. It also wouldn't raise any new data privacy issues for Phacility customers since we wouldn't have to deliver pushes outside of our existing VPC infrastructure. List of supported push targets:

See PHI500 and T13179. Recent versions of SSH support passing the key fingerprint to the AuthorizedKeysCommand by specifying it like this:

D19935 prepares for multiple MFA provider types.

Maybe worth a mention -- GHC is another somewhat-similar project and moving to GitLab (e.g., https://mail.haskell.org/pipermail/ghc-devs/2018-October/016425.html). It sounds like GitLab is currently better able to spend resources to support free users with relatively non-mainstream use cases than we are.

For the record, yes, FreeBSD is quite similar and what @chandlerc wrote is very much applicable to our community as well.

I think a lot of this behavior may be fairly unique to the LLVM project, since we've never really received this general class of feedback from other installs (except, perhaps, FreeBSD, which I think is somewhat culturally similar).

For the record, while the rationale can be flippantly described as "I don't like clicking things", I'd like to give it a serious description.

This is the most upsetting bug in the software.

I'm generally very hesitant to "nag" users, and this conflicts with T7477 (which wants email to a group of users, including an application email address, to work). Of the two, I think T7477 is significantly more valuable. And, some day, many years from now, I'd theoretically like to make metamta.one-mail-per-recipient the only supported mode, which fixes this anyway.

This is a big chunk of work with no current customer interest. It could be implemented as a third-party extension today; otherwise I think it's unlikely to move forward without customer interest.

These are so niche that I think we probably don't want to formally support them in the upstream.

I don't plan to change this without a better understanding of what problem we're solving. New users can click the link in the email to review the discussion, summary, and patch.

See also PHI1011. I think the fix here is likely easy, but I'd like more clarity on:

(Must Encrypt Mail is a magic meta-tag for testing the feature, not an organizational tag.)

See T8962, somewhat. When receiving inbound mail, we could decrypt PGP messages and verify PGP signatures.

It sounds like behavior here is basically correct/expected (content is treated as content; attachments are treated as attachments) and the original report was a top-posting vs quoting issue perhaps (see also T5181), just not ideal (preferable would be validating the signature, or at least discarding these attachments).

The existence of alternate ... code signing standards would motivate

It seems like any client which has this behavior must always break when a user is added to an existing thread (via, for example, "Reply All" + add them as a "Cc"). I think we're either missing something significant, or those clients (possibly just KMail?) aren't handling this situation correctly and this is a bug which should be fixed in those clients rather than Phabricator.

I'm not confident there's really a path forward here even for the subset of mailers where we have full control of the SMTP envelope and can generate Message-IDs, which is only a small subset of mailers today. Even if it does work, it makes the "Reply All" problem worse.

Not clear that "Sender" is worth pursuing, even if it does give us more flexibility around configuring the "From" header in some cases.

This is years old and I have no idea how to reproduce it. (I use Mail with "Organize by Conversation" as my primary mail client, and have for about a decade.)

This logic should probably look more like this [differentiating between explicit senders and receive-as-users].

As tends to be par for the course, this is turning into a bit of a rabbit hole.

I expect Google to expose a similar solution to Duo soonish (if you use Android and try to login to Google, MFA is just like Duo now).

Some of these things are supposed to be implemented in a reasonable way via browsers "eventually" (offline push notifications have a bunch of attempts, Screenshots use case has some solutions that sometimes work, and there's rumor about MFA and NFC floating around.)

I'm considering pushing this forward since MFA is getting an update (see T13231 and adjacent tasks).

I expect to make TOTP configuration a concrete object, then pursue Yubikey/U2F (T8787) and Duo (PHI912).

• Also, comment interactions should get a warning when you'll be required to MFA on submit, especially when you don't have MFA on your account.

...it is virtually inconceivable to me that this is something we would ever bring upstream in any form.

Also, just so I don't forget:

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!