Would anyone give this another review? Might make sense to apply the one-liner in D25527 to have a simple test case on the Maniphest Advanced Search page

On the other hand, as the variable is called $html_details let's go for phutil_implode_html() to be super-safe? ping @roberto.urbani

CVE-2017-5223, CVE-2018-19296 and CVE-2020-36326:

CVE-2021-34551:
This one requires passing user-provided input as a filename to the "setLanguage" method; We don't call that method.

First pass, these one do not apply to us (and some of them do not apply to anyone at all):

(I've put a note in Dependencies for now)

add inline documentation because we can

In D25546#15665, @valerio.bozzolan wrote:

I also don't get if in this part we have access to any thing related to Maniphest, ManiphestEditEngine or this kind of stuff, to just call $something->getCommentPanelPlaceholder() and have the business logic there in the specific application itself.

Let's split the problems:

Updated Pygments with pip to 2.17.2 und cut the time in half. So yeah, that's already an improvement.

I guess we could also try to cache the individual rendered code-blocks.

I assume we should change strpos("\0", $value) to strpos($value, chr(0))

(and I made sure this new function isn't exported to the arc lib namespace)

extract to function

Well, good to know that it is not something in the phorge codebase. Our server has pygmentize 2.14.0 - but the server itself is really not the best, so that could be an explanation. Maybe we could make some remarks about performance and keeping the versions fresh on the diviner page...

There is still that minor inline comment here, maybe interesting

Yeah, it's probably not impossible to so safely - especially since people has been working on it for over a decade - but it's hard to do right. I know Wikipedia allows user-uploaded SVGs in some way, so maybe this is a solved problem.

I fixed arc test-traits in R12 (45f900a587).

@avivey I have no idea if they are actually any good but PHP based SVG sanitizers like svg-sanitizer exist. I also noticed this Rust based library made by cloudflare svg-hush.

lol

Update: I've installed pygments (2.15.1), and it took about 3 seconds to render. It takes about 14 seconds here (with pygments 2.3.1).

mm, dumping this file in my dev env renders pretty much immediately; that's a good sign that it's the code blocks, because (1) pygments is known to be slow and (2) I don't have it installed.

Ah, I see - that makes sense. Thank you for the detailed response.

I'm quite sure the problem is limited on repeated code blocks.

"slow remarkup" often boils down to 1-2 inefficient regexp in a rule somewhere.

Can reproduce

In T15670#16064, @valerio.bozzolan wrote:

A root problem is that highlighted line number(s) should be a # fragment really, to do not multiply pages exponentially.

Apparently PhutilSortVector.php is somehow recent, 2016, without any comment about that strpos("\0", $value) that is probably not correct

I also don't understand strpos("\0", $value) since the documentation says that the second argument is the needle

In D25051#15888, @valerio.bozzolan wrote:

I'm a little worried about this migration; Do we have garbage collector for this? it would be safer to let it run.

You are concerned for performance reasons because it doesn't limit the results. Right?

refactor as recommended

Thanks, this is way cleaner (and slightly more performant) than my D25476. I've tested this locally, also in combination with other actions (e.g. opening another action field without changing it) and behavior is as expected.

remove unuseful line - thanks

Superseded by D25550

Would you like to go to court to defend that statement? :)

OK OK. So what else? Maybe this (mention from https://secure.phabricator.com/p/epriestley/):

I could not sign it if it required brushing three times a day. Removed purely due to egoistic laziness reasons.

No brushing teeth three times a day? However it looks good to me 👍

yep!

Well, I would rewrite quite a bit, so I'll post a draft here before editing directly:

Looks good to me. @speck

I forgot to invite the original author. This modification would not exist without aklapper. Eternal glory to aklapper.

Possible further enhancements, which I am loathe to do when trying to fix an existing bug, so perhaps as a future diff:

As per @avivey, update ArcanistPhpunitTestResultParser.php to call ArcanistXUnitTestResultParser and remove it's own XUnit parsing code.

Yeah sorry. That exception also occurred to me, before this change: https://we.phorge.it/transactions/detail/PHID-XACT-TASK-tuchgj42nb2ujtc/

I could not even reproduce but get an informative error instead:

As Wikimedia uninstalled Differential I cannot further debug in downstream.
We can either decline the ticket and its patch for now (if someone runs into this again, they could reopen or file a new task), or could get the patch in (setting a default value) without a test plan to have more robust code. Shrug.
Opinions? :)

As Wikimedia uninstalled Differential I cannot further debug in downstream.
We can either decline the ticket and its patch for now (if someone runs into this again, they could reopen or file a new task), or could get the patch in (setting a default value) without a test plan to have more robust code. Shrug.
Opinions? :)

Also interesting: https://github.com/phabricator-docker/phabricator by @tsc (Thanks!)

Since 2023, Wikimedia Phabricator is really Phorge.

I'm not a fan of "if not nonempty". Can I swap?

Thanks avivey. Added this:

Look into the "is creation xaction" - we had a similar diff recently about creating Revision from raw diff that had a similar behavior.

A root problem is that highlighted line number(s) should be a # fragment really, to do not multiply pages exponentially.

I'm a little worried about this migration; Do we have garbage collector for this? it would be safer to let it run.

Also, maybe combine with the ArcanistXUnitTestResultParser.

So maybe rename the parser to JUnitTestResult, or something like that (If that's the right name for the format and if phpunit is using the same format)?

@speck , @valerio.bozzolan
Sorry, yes, it's updating the test engine to parse phpunit's junit output, rather than the json output which no longer exists.

In D25472#13979:

is ArcanistPhpunitTestResultParser now learning to parse generic "junit style xml" format?

This seems reasonable but better to find a test plan. I also tried, without success :(

I cannot reproduce this. Can you?

Thanks Roberto. If you have not time to follow-up, no problem. We can help to re-patch.