The tools to perform this export are available in that project already. We don't plan to run the tools for you, since this just makes the workflow more complicated: you already have access to the tools you need to do this yourself.

This is now in master so I've made the task public.

I don't want to leave RCE in Phabricator for 3 weeks, so I'm planning to land, deploy and disclose some version of the patch above today.

(I change visibility for this to @epriestley, @amckinley and @durin42 for now -- note that I intend to eventually make this issue public once the fix hits the commit log, so don't stockpile all your 0-days here.)

This doesn't seem to have caused any issues.

The other major thing I tried was throwing exceptions when the values for %s, etc., contained --debugger or --config while constructing Mercurial commands.

I have a not-so-great patch for this ready when Mercurial makes a decision. This isn't great, but it's the best I could come up with after trying a few things.

In reply:

From @durin42, via Mercurial Security:

We need something like this too because the exporter doesn't include points at the moment.

Could this be closed now that Phab supports this? (in /settings/user/Username/page/notifications/)

(Another possibility is to add behavior to arc to control this.)

Maybe. Another possibility is to mark builds as "nonblocking" in some sense. There are some other open requests for defining "advisory" or "noncritical" builds where build failure doesn't cause the Buildable to report a failed result overall. If we end up adding this state to builds anyway, it probably makes sense to include a "Does Not Block Review" flag to the "Does Not Fail Buildable" / "Does Not Block Dependent Builds" / "Failure Is Totally Meaningless" / Whatever flags.

The harbormaster builds that we have running on revision creation can sometimes be rather slow; they're builds in our primary CI system, but with less of a priority than jobs in the submit queue. This will result in 10-30 minute delays for every revision in our monorepo. I understand the preference for only adding configuration settings when absolutely necessary, but since this may result in a significant time sink for any installs with expensive builds, is it worth keeping something around like differential.initial-state?

For any body still interested, the project was in PHP, I had to rewrite in go, so it can be used elsewhere.

Pretty sure T7704 is the same as this.

PHI181 has an entangling concern (T11372).

Generally, this sort of discussion is better on Discourse (https://discourse.phabricator-community.org) than here.

From T10109, we shouldn't make revisions "Buildable" to Herald if the update is an automatic update in response to a commit being discovered.

Ah, thanks. I think your guess is right. I'll make a note in T2543, should be a one-line fix I think.

From https://discourse.phabricator-community.org/t/644 - it appears that HM now triggers a build on revisions when they are closed via landing, which fails because the build expects a Staging ref. I don't have the setup to test any of it, but the latest revision landed here doesn't show the behavior, so either f7f3dd5b2084 hasn't rolled in here yet, or that user is doing something funny.

In T8552#233072, @mejaz wrote:

Why is Phriction being kept on such a low priority? This task has been since 2014 if we take into account this: T5254: Allow top-level wiki doc to display entire document hierarchy instead of only 2 levels

Why is Phriction being kept on such a low priority? This task has been since 2014 if we take into account this: T5254: Allow top-level wiki doc to display entire document hierarchy instead of only 2 levels

After all that stuff:

Additionally, arc diff no longer dispatches ArcanistEventType::TYPE_REVISION_WILLCREATEREVISION if the server is sufficiently modern. (It no longer uses the datastructure this event received.)

See T2543. The flags related to previewing a diff have changed:

oh, nice work, it will trigger parent task as well when subtask changed, seems I need to add the "condition" like subtask status instead of a "action" for this... any samples? Thanks!

Question: When subtask was fixed, the parent task want to have a action, for example, add a tag or change status if all subtasks were fixed.
So how to get this work in the extention of herald action? Thanks in advance!~

This is technically accurate but real awkward for humans:

I pushed secure004 with that patch and it worked fine, although mysql came back up fast enough that we didn't have to wait. Since I don't have a way to actually trigger this condition, I'm going to assume this is resolved until we have evidence otherwise.

This has been stable for about a week now.

This traffic eventually stopped on October 20th.

The pruned (at 0.15 threshold), optimized ngram index for the original affected instance is only ~13GB, which is entirely manageable with the changes to backups, and we haven't run into other issues.

We hit one of more of these (db024) last week so D18725 should fix it.

In T5463#172345, @florianb wrote:

I ran into the same issue, it turned out, that the permissions for /phabricator, /libphutil and /phabricator as well as for the preceding parent-directory had to be 755.

Until i figured this out i tried running all directories with less permissions (750) - which did result in a

AuthorizedKeysCommand /usr/share/phabricator-ssh-hook.sh returned status 126

I really don't know which user is here trying to invoke whichever script or command (since all defined users [git, phd, www-data] are nicely coupled in their phacility-group), but since i wasn't able to track that down i think that's a good compromise. And it should be safer than letting root invoke the AuthorizedKeysCommand.

In T12856#231964, @pouyana wrote:

I wrote a small dynamic inventory client (based on almanac /passphrase conduit API). It is not open source but I can open source it, if there is a need.