Thanks - I did mean as an inline comment in the code but either is good.

Is the input to parseDiff guaranteed to be UTF-8 encoded? I don’t have the code on-hand to look up but it’s possible encoding is handled elsewhere — or arc might have a hard requirement for all input to be UTF-8. All mercurial commands run by arcanist are done with a flag to enforce UTF-8.

Hmm I’ve used mercurial and arcanist/Phab for years at my company and don’t believe we’ve ever run into this. Any idea what’s causing the presence of the BOM? We’ll apply a change to handle the UTF-8 bom but I am curious what may have caused it to show up. Is your hgrc configured in some way for this or maybe an environment variable?

Same comment about keeping strlen. Up to you if you want to switch before landing.

ty

I have some containers I put together for development which could provide a place to start
https://github.com/neandrake/phab-dev

Also instead of “Goodie” maybe “Helper” or something. Maybe there’s a similar naming elsewhere in the code base

I forgot I had this requesting changes. Any idea of the performance hit in markup rendering now that PhutilURI is constructed for every link? I think its constructor does a fair amount.

Thanks!

I’ve been meaning to investigate this. It also has thrown me that it’s not available where you expect it. I do suspect @valerio.bozzolan is right

It might be safer to do a null check with the strlen check in case the value isn’t a string.

Good catch. I don’t think it would cause an implosion but might result in not applying constraints when it should

Whitelisting both vs and id sound good.

I spent only 5 minutes playing around on a diff to see what might make the url change. The diff id is probably the key one I’d be interested in keeping. I don’t know what the other params are for (even vs).

Hmm that stack trade doesn’t seem to contain the origin of the issue, likely getting lost through error handling or maybe it’s an incomplete stack trace.

This seems fine, though I wonder if we should introduce a phutil_empty_string() or phutil_is_empty_string function to avoid the double-negative logic. I think this reads more easily:

if (phutil_empty_string($from)) {
  throw new Exception()
}

Is there a stacktrace to work from here? I suspect nothing should really be passing null into phutil_encode_log() and there's likely another issue here. I prefer preventing passing null values into this rather than papering over the issue here in the depths of util functions.

Thank you so much for the header fix that’s been bugging me every time I use conpherence lol

Thanks for staging this @valerio.bozzolan

6 year old in-your-face unreported bugs like these make me wonder how many people use Phabricator/Phorge :-(

It's not many, but this issue would be specific to anyone using Phabricator/Phorge for PHP development, which is likely Phab/Phorge itself is close to 100% of that market. And Phab/Phorge also itself has its own unit testing framework instead of PHPUnit.

What do you think about keeping the current naming scheme but whitelisting a handful of query params to use instead of using them all? The timestamp adds noise and it's probably nice to see the ID of the diff in the filename, e.g. D25478.id1541.diff? Maybe just allow the the id parameter and regex that it's value is just a string of numbers.

Sorry for the delayed review

Oh interesting

Was this the result of a recent change?

I don’t think revert I’d needed but the comment should probably be removed or updated. I’d like to understand why it was deemed hard to do but the solution here doesn’t seem that hard. Maybe it’s more difficult than it appears, or was robots.txt standard later updated in a way that makes this easier, or maybe Phab URLs changed in a way that made this easier but this was never updated, etc.

Minor, just suggestion

I think there’s still a chunk to do here, including additional documentation during setup

Opening this up from draft if communication/reviews are happening

Okay I misunderstood the default value. I don’t think a security tag is necessary either.

This will require documentation of some sort, specifically for the upgrade notes to indicate that if someone relies on rendering PDFs currently then after upgrading they would need to update that configuration.

The Referenced Files section of this diff looks like someone is looking for a vulnerability. Any idea what’s happening here?

Since this is for the timeline text maybe it should check for array and just say “multiple images” rather than grabbing the first.

Thanks!

Awesome thanks for adding details and clarification

This seems reasonable to me. It only adds further information to logs. I suppose there are some paths that could result in showing exception on the client-side but including monogram doesn’t seem concerning/dangerous.

Would there be a bunch of these lying around?

Is the list of PHIDs referring to what types of objects that it creates? Is the expectation that each PHID type corresponds to exactly one Application? Maybe some additional text on that page to explain more what PHIDs mean in this context.

This looks like a reasonable chance to me.

Nice

Great points. Thank you for talking through more details.

Nice, thank you!

Instead of adding a checkbox is there precedent for having a separate button alongside Cancel and Submit?

I’m surprised the monograms weren’t already defined on the applications - those should be somewhere already, right?

Basically it works

😂

This looks good and I really like the idea of being able to customize the style of external links. Just one tweak to the logic I think we should add before landing.

Looks good to me, I suggest clarifying the comment before landing.

Maybe add some doc - the view and edit actions being lumped together are because it would be a larger change to split out that functionality right now, correct?

Thanks for clarifying this behavior, it sounds like contact numbers in general need fleshed out quite a bit.

Changing policy based on sms being configured seems a little off to me. Having the setting only conditionally show based on it being configured seems fine, however what happens in this scenario:

1. Turn on sms
2. Add number
3. Turn off sms

I had communicated these upstream (almost exactly a year ago~) and some helpful information was provided

Could this be abused, e.g. create an event with a thousand emails then import it and see if those emails are registered? If so how does that compare to existing means of discovering registered users?

This is a good plan. Would this be opt-in, e.g. this Phorge instance would be the main one with this on but other installs wouldn’t see this by default?

I have this working now in https://we.phorge.it/D25276. I still have it marked as draft because there are some outstanding things that should be decided/addressed

1. Whether client certificate should be configurable. Ideally this is something that would be configured in the php.ini rather than directly in phorge but at the moment I don't think it can be.
2. Updating documentation to specify how to set up TLS/SSL. For database configurations there's now a use-tls flag which will require connecting to the database using TLS. Turning on TLS/SSL on the database we can probably provide pointers but it's left to the reader for determining that based on their database.
3. Database clusters with master & replicas? I don't know how to set this up. Those changes might affect cluster dbs but I'm unsure and it's untested.

I picked this up again recently. I’m stuck on getting mariadb valid certificates it uses for connections, for testing my Phorge changes.

We don't allow cross-application table joins

• Is it possible to make Phorge use a different database? Adding SQLite support could greatly reduce complexity and lower the barrier for entry for new developers and allow running Phorge as a standalone app.

Phorge/Phab support a variety of different setups, including support of clustered MySQL/MariaDB databases. Moving to SQLite would be a large undertaking and would not support clustering/replication without major overhauls. For a move like this I can only conceive of many downsides and no benefits.

It all comes from the fact that PHP was designed for a web 1.0

I don't follow this logic.

Awesome, tyty

Nice. Could we add some additional tests for Boolean true/false, the number zero, populated and empty array?

I agree that non-string/null should be handled differently. I guess I don’t see the difference between null + strlen being used vs. the proposed nonempty_string/stringlike, and that making that change is explicitly acknowledging that casting is expected/intentional when it isn’t and instead the different types should be handled appropriately (your suggested long-term solution).

phabricator_form() is called in 24 places, and 23 of those specify the method.

So the choices are:

1. Update the one calling place which isn't specifying the method, but leave phabricator_form() as a fragile function.
2. Update phabricator_form() to defensively handle the lack of a method attribute, as we have done here.
3. Update the phabricator_form function signature to make the method a required parameter.

Wouldn’t this be better as a null + strlen check? It was originally a strlen I assume.