For completeness, my arguments against this:

(I'm against this, but I don't have the time to go into details right now. I suggest a CLI tool (like ./bin/user) to expose this information).

I didn't read the whole novel in the description, but keep in mind that remarkup is very performance sensitive, so make sure not to add any complex algorithms.

I don't remember the details; It's possible that a CSRF token is created in the Form class ("PhabricatorForm"? "PhutilForm"?), and is only available in POST responses ($request->isFormPost()).

I'm ok with this change, under the T15457: Update installation docs to talk about linux users umbrella.

From reading the docs, safe.directory should respect command-line arguments, but at least in 2.34.1 it doesn't. If recent versions do respect it, it might be simpler to just add -c safe.directory=.... to the command rather then passing $HOME.

In T12071, @epriestly mentions that individually selecting env-vars to copy "build[s] some resistance to "Shellshock" class vulnerabilities", which is kind of a compelling argument.

For now, rejecting this change until we can get a better understanding of the root issue.

Ok, looks like my personal install is missing $HOME as well, so I can probably try to reproduce.

A few style comments, but otherwise it's ready.

Would it make sense to put creating identities behind the existing Edit policy of the repository?

The primary feature is to immediately reject any support query for PHP 5.

(As a member of Trusted Contributors, you can use the "Create Task" button to directly file tickets in Maniphest. The "Ponder first" approach is/was mostly intended to keep non-community-members from flooding the task list).

I'm inclined to actually implement this, partly because (AFAIK) nobody on the team is actually running on PHP 5 to check for problems.

I'm not, personally, 100% convinced that the hooks should be blocked from running on these refs - there's plenty of edge-cases where this might be even more confusing (commits can become published in a bunch of ways).

In any case, it should be generic - on "search results page", although probably requires each SearchEngine to define the available fields in order to actually support this feature.

You can already "export" to json from the conduit. Maybe "teach conduit search methods to produce csv" would be a better solution.
Alternatively, an external script to convert the resulting json to a csv.

• fixes

Yeah, it's not totally unreasonable (except for the option to disable the behavior - see https://secure.phabricator.com/T8227).

In that case it seems logical to treat the action of updating a published ref as having an immediately preceding action of pushing all commits in the new ref — just for Herald purposes.

In T15091#9775, @RhinosF1 wrote:

Can this be made public?

It's 2023, I think "not supporting TLS" should count as "high pri bug" now.

Closing for now as "we're ok with this", and there was no interaction on this ticket for a while.

A friendlier UX might be to add a button/checkbox for "ignore this conflict".
This can be implemented in either the controller or in javascript, to act as if the user selected "ignore" in the drop-down).

From a quick glance, looks like the ajax for the graph content is returning a login form or a js redirect request (with status 200), and the handling code in the report page doesn't properly handle that.

Screenshot of the current config page of this install:

The config page shows correct versions both here and in my personal install, so I guess they have a $HOME.

yeah, ./scripts/celerity/generate_sprites.php. It will also generate the sprite files (and after that, bin/celerity map)

Before this change, some git commands here were executed without any HOME...

@valerio.bozzolan Will allowing a Timezone option in the user's "Date Format" solve this?

This is probably a configuration issue - mine shows "This install does not have any active MFA providers configured".

From reading the last messages in T109 (starting https://phabricator.wikimedia.org/T109#8874116), it sounds like adding that text will be bad for screen readers, because it will add lots of repetitive, "un-useful reading" to the page.

(Raising to "HIGH", until we figure out if there's a security concern).

The text says "The user who uploaded a file can always view and edit it.". I checked the DB, and the author field for the relevant file is null.
That implies that this upload code is bypassing some security checks...

I think a more generic solution here is "Make the Remarkup Help Page Extensible", so that Remarkup rules can add their own sections (Possibly under the Guides application, if it still exists?)

I was intrigued that Evan added the perl version in the first place, but I went and read the licenses and I think it's fine to remove these parts.

In D25234#7306, @valerio.bozzolan wrote:

Just to clarify: I think we both agree on these four things:

1. showing a "No interpreter error" to the frontend could be weird, at minimum this is true for MediaWiki users (not just Wikimedia users) and showing the original raw text could be more useful (green light)

That sounds very sketchy - getMatchingLineCount should either refer to raw text, or to post-processed text - and the 2nd option isn't possible (There might not be any text in the result, like in macro).

Where was it "returning an error message with potentially a different number of line" ?

I don't see how this stops the exception discussed in T15372 - nothing in this change looks like it might stop an "Undefined array key" exception?

I prefer if ($thing !== null && strlen($thing)), but whatever.

lint