Some possible implementations of this expose an open redirect (e.g., by passing returnURI=<something> where <something> can be anything). An open redirect here isn't necessarily inherently dangerous, but the minor inconvenience we'd avoid probably isn't worth the security risk.

Broadly, I think this is better expressed as "Commits in rXYZ on master, including build status" than "Builds of commits in rXYZ on master". Diffusion proper already shows build status in commit lists, although the commit query in Audit currently does not. This probably won't get an update until T10978 happens.

As a followup, ran this script on a subset of instances to collect data about mail delivered on a per-action basis versus a per-user basis:

Per above, here are the specific queries I executed while collecting statistics about the "Self Actions" preference:

I am running a query to collect this data:

Circa September 13, 2016 we ran a query which collected this data from instances:

Ah, thanks! Yeah, looks pretty conclusive.

This is expected.

I'm vaguely suspicious that the mail is just too big (1MB of text plus tons and tons of HTML for syntax highlighting it?), and that the error is really arising from max_allowed_packet being violated, particularly given that the INSERT took 233ms to execute.

This feature request does not describe a root problem. See Describing Root Problems.

(If the policy isn't fixable, you can personally bear the cost of this policy by tunneling the traffic over 80 or 443 locally.)

Have they asked network operations to allow outbound traffic on port 22? It seems like organizations which employ software developers should reasonably permit this traffic. Particularly, security-minded organizations should reasonably prefer asymmetric keypair authentication over HTTP password authentication in the general case.

See Consulting if you'd like me to help you personally. Thanks!

• To click the "Land Revision" link, you must be able to push to the repository.
• The push is performed by the user that Drydock is operating as on the automation host.
• The reproduction steps and video above are consistent with this.

It's safe to do that (set utcInstanceEpoch = utcInitialEpoch for all events with a parentPHID where utcInstanceEpoch is currently NULL), with one minor caveat.

Why are users logging into sensitive accounts on shared computers? This action seems inherently unsafe to me.

Update past D16623 (Sep 28). See also T11705.

The upstream still doesn't have a reproduction case; we won't act until we have one. See Providing Reproduction Steps.

That change doesn't specifically do anything about mail tasks, but assuming they were coming out of repository imports it should probably clear them up too. I'd expect queue behavior to generally be more reasonable around repository imports once you pick up those changes.

Did you experience these issues after D16585? My expectation is that it should be almost impossible for PhabricatorRepositoryCommitHeraldWorker tasks to stall the queue for other priority-2000 tasks after that change.

@20after4, just a heads up about this per discussion in T7944. Here's what we expose today:

Well, just Conduit for editing -- querying is already in D16592.

I think making authorizations transactional isn't too much work. They already have PHIDs, and aren't edited in very many places.

I'm comfortable bringing this stuff upstream today:

(That doesn't solve the "engineers don't know how to initialize a new Git repository with git commands" problem, but I think that one's a bit more involved.)

I'm assuming the "empty" issue is that you have a rule like this?

If the major immediate issue is Herald disallowing branch creation with git push, we could add a Herald condition like "Repository is empty".

Here's what I'm planning to do for imports:

Hrrm -- what is max_allowed_packet set to in MySQL?

T11747 wants a more advanced version of this (reviewing diffs between rendered documents), although the specific document type it wants (IPython notebooks) is likely very complex to render.

I'm going to merge this into T5698. That isn't quite the same task, but would be the first step toward this.

I believe this should now be fixed in HEAD of master. It should promote to stable within 24 hours.

T11744 has a vaguely-related special case where "split + count" was unreasonably slow for very large inputs.

D16683 makes us bail early if the combined length of the old and new lines is larger than 1280 bytes, which is a crude test for approximately two reasonable-length lines of emoji source code.

It looks like this is largely just PHP being PHP. To handle UTF8 combining characters correctly, we're producing a list of strings like this internally as the atoms of comparison:

This should now be fixed in HEAD of master.

I'll look at this tomorrow but can probably figure it out from this. Initial guess is that we're doing this (which is O(big constant * string length)):

The root issue was that we would compute a ProseEditDistanceMatrix (roughly, a Levenshtein distance matrix) for large inputs, but this is O(N*M) in the size of the inputs and both of these inputs had ~2,200 "atoms" at the top prose diff level, so the matrix had ~5M elements.

Oh, one diagnostic tool that I didn't mention is that you can send SIGHUP to a running bin/* command to get a stacktrace of what it's doing dumped to /tmp/phabricator_backtrace_<pid> (usually). This one looks like it is a smoking gun:

Awesome, thanks! I'll dig into it and update you once I get somewhere.

Yeah, just take a shot at making a paste here (secure.phabricator.com) with the same degenerate behavior. If you can get us crashing I suspect I can get a fix in about 5 minutes through the power of adding var_dump() all over the place on the production server. If not I have a few ideas but there's a lot of code that could be causing the problem and that trace isn't an obvious smoking gun to me.

One other quick diagnostic is: when the worker is stuck, is there a pygmentize subprocess running?

Can you attempt to create a paste on this install which reproduces the issue? I have a few ideas about what's up, but that's almost certainly the fastest path to a fix if it works.