@bcooksley, feel free to mention that you've talked with me about stuff when filing tasks in the future. Like 90% of what shows up here spontaneously is pretty questionable, so unannounced reports get fairly strict scrutiny.

Here's the downstream task: https://phabricator.kde.org/T5406

Note that these steps depend on who is viewing the page (or, specifically, who "Responsible Users" are). More concise steps are likely:

It looks like we currently allow usernames to begin with _, ., and - (PhabricatorUser->validateUsername()), but maybe just do a ? for anything-except-numbers-and-letters?

Have you tried using Lock/Hide Fields to hide the "Status" field?

What's an example of a specific change you're trying to make which you aren't able to figure out how to make?

We can draw letters in GD, but I suspect they won't look very good compared to letters from Photoshop (bad antialiasing, limited font choices, weird alignment/kerning issues), so I'd guess it's not worth bothering and we might as well just jump straight to using generated images like Projects.

You are running an out-of-date version of Phabricator, from February 17th.

Please provide version information for your install. See Providing Version Information.

I think this (and lint/coverage) should move to Conduit, yeah.

(That said, my expectation is that behaviors around unreachable commits have not changed -- D17279 added the "Unreachable" option to solve this problem.)

Likely somewhere in T9430 / T10978, which rewrote a big chunk of the audit code.

If you don't want to see unreachable commits, use a query which hides them:

It is expected that some deleted commits will import and others will not.

See T12298#213181.

Total cost is about 1.6s. Of this:

This is still a little bit of a pain but far more reasonable now, here's an actual profile:

I cycled the rest of the tier and things look better now.

After manually deploying that to repo001, I'm now seeing a consistent Taskmaster/PullLocal count. I'm redeploying the rest of the repo hosts.

I think the issue is that the --reserve flag for reserving system memory now applies to even the first daemon in a pool, because all daemons are now part of pools. Previously, it only applied only to the 2nd..Nth daemon.

Some taskmasters failed to start on repo001 and perhaps elsewhere.

I suspended and destroyed the largest instance on the shard, a free instance with one user and no logins for >30 days (the user appears to have imported a huge repository and then never logged back in). We still have backups, but this instance was way over reasonable resource use anyway. The volume is now 78% full.

I pruned some very old backups (backup pruning is currently very conservative in several cases). The volume is now 72% full. This could easily be reduced much further by allowing bin/host prune to remove backups older than 90 days for suspended/terminated instances that have been out of service for 90 days, but backup utilization is generally relatively stable so I'm not concerned about this.

I synchronized services for this shard and destroyed old instances. The volume is now 68% full.

I synchronized services for this shard and destroyed old instances. The volume is now 44% full.

This was a bunch of repository file data in /tmp. Each file was unique, so this doesn't look like any sort of buggy loop or anything. There's some actual bug here but since there's a long list of other issues here I just "fixed" this by clearing /tmp.

Some reserved instances ended on Feb 19th; I should make sure reserved instances match production instances.

Shards 017 through 020 are now in production.

The re-launched hosts seem OK, I'm waiting for DNS to update and then redeploying them.

The hosts launched into an "Auto-Assign Public IPv4" subnet but didn't get IPv4 addresses. Restarting them didn't help, and there's no apparent way to assign public addresses after the fact. I'm going to throw them away and try again.

I'm going to put more hosts into production immediately before pursuing other issues.

• Some reserved instances ended on Feb 19th; I should make sure reserved instances match production instances.

• The tier as a whole is 88% full.

So here's a tentative plan for subtyping:

Custom Forms are the general tool we want to use here, but they currently have some limitations for this use case. As a starting point, here's what they can do today, some of the strengths, and some of the weaknesses.

Maybe the "Install Arcanist" header on Quick Start could be like:

That is, this passage:

There's a short version and a long version. Each version links to the other version, saying "here's a different version of these instructions, if you'd prefer that one". How could we make this more clear?

This is a followup to a private discussion elsewhere, I'll flesh it out a bit when I have a chance.

Hibernating daemons currently show as "Waiting" in the Daemon console, but I'm not going to worry about that for now.

Ah, okay. This is the relevant part:

good luck w/ teeth 😁

Starting with repository update:

Broadly, there is nothing Phabricator could have done differently to anticipate or prevent this issue.

We could also provide some kind of bin/auth burn-everything-to-the-ground to automate these steps, but I worry that it would almost never be tested (I think it's very difficult to test comprehensively in an automated way) or run, and there's a good chance it might be forgotten about when authentication changes occur.

Ah, you're right. It looks like request data may also have leaked. I'll edit my earlier posts to reflect that. Briefly, the change is: passwords and VCS passwords are potentially at risk.

To cycle passwords, you can do this:

Although this problem is severe, the absolute size of the leak appears to be small (my task title is hyperbolic). From the Cloudflare disclosure:

Thanks for the report! This should be fixed in HEAD of master, and promote to stable tomorrow, a little more than 24 hours from now. Let us know if you run into any issues.

Thanks for the report! This should be fixed in HEAD of master, and promote to stable tomorrow, a little more than 24 hours from now. Let us know if you run into any issues.

I didn't "ref" it here, but D17401 sort of technically did this. I'd like to clean it up a bit more before calling this resolved, though -- particularly, this is basically a secret that only I know about.

Also, above, I used the term "deuteranomaly" when I meant "deuteranopia". I mistakenly believed they were describing the same type of colorblindness, but they are two different types.

Possibly this should really be three dimensions (Size, Contrast, Color Correction).

See T12060#213081 some end notes and followups.

See some additional discussion in T12172. Briefly:

@chad did another pass on user hovercards and they should be even more clear now (this screenshot doesn't demonstrate it clearly, but we also greyscale the profile photo);

Why do you have multiple authentication providers?

Yeah, I'm basically just keeping this open as a dumping ground for the moment and purely selfishly because my segfaults aren't resolved yet -- brew didn't have PHP 7.1.2 last I checked, although it seems like it now does. I've upgraded and I'll see if that improves things.

We need reproduction instructions which allow us to reproduce this issue in a clean environment. See Contributing Bug Reports and Providing Reproduction Steps.

This has been "resolved" by switching to bartering various sundry goods and foodstuffs instead of billing via credit card.

No time like the present.