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.

Is there another place not specifying the method for a form? I don’t think that attribute should be optional and instead the fix is to explicitly declare GET or POST or PUT for forms.

In discussion over a support ticket one of the potential options that was discussed was having a "An MFA challenge is about to appear, click to continue" prompt in the workflow as a means to prepare users to get their phones/devices ready so they can respond within the 30 seconds. Right now since MFA is opt-in per each user instead of required per auth portal - the current login workflow will immediately prompt you for MFA after successful login, which might surprise users who fumble to get the TOTP code out (it's happened to me).

The comments in https://secure.phabricator.com/T9770 discuss the "spyglass" attack and how this behavior is meant to be more secure.

nice

Very nice

Is it legit for this function to return an array instead of a single item? That’s the only structural question I have- everything else looks good and just some nitpicks.

Code-wise this looks good, though I’m not overly familiar with CSS or how Phorge uses it. Ready to accept after the empty icon thing is resolved.

This looks great! Thank you for working on it.

Just clarifying - this is for specifying the initial default value for the Default Branch field that can currently be edited after creation?

No worries, I haven’t had time to dig in. I wanted to review D25067

Thank you for clarifying!

I had discussed this with Evan previously and he gave a great explanation for why the current behavior exists, something he refers to as “spyglass attack”. I’d have to go back and review the explanation. What I recall the outcome being a few options, one of which was prompting the user that they are about to be promoted for MFA before issuing the challenge, to give the user time to prepare.

Thanks - the behavior I was seeing I think mirrors your own but the error I was getting was more directly related which confused me. It seems using @ does not clear the previous error from its use? Bleh.

I think updating the user script is a good idea if this functionality is needed.

I like this idea. A few things I want to note

1. Could you post a screenie for what the breadcrumb rendering appears as?
2. Does the name of this new class follow other classes that extend the hierarchy? I’m guessing yes but just want to double-check.
3. Maniphest tasks will render their primary Space (assuming non-default) as a prefix to the title. I think wiki docs should do similar.
4. Do wiki docs have a description field?

I wonder if there were plans to incorporate contact numbers with the prototype app for handling support (the name escapes me).

Something like this, though I'm not sure if this is actually correct - in PHP8 using @ will still throw a ValueError if passed an invalid encoding. But I'm not sure This @ thing is working as expected in php8, or I don't have a valid test case.

$message = null;
try {
  $result = @mb_convert_encoding($string, $to_encoding, $from_encoding);

I think this change is removing intentional design. The reason that @ is used instead of try/catch -- the comment on the function is saying if you have a string in e.g. Latin-1 and $to_encoding is set to something different-yet-valid such as Korean (e.g. ISO-2022-KR) -- then the encoding conversion will silently fail, not throwing an exception, but still populating the result with incorrect garbage. The exception only appears to be thrown if either of the to/from encodings are invalid like lol or asd. This is likely a breaking change.

Still accepted~

Do you think this also requires the strlen() check?

Thank you!

Thank you!

Similar here, on transactions it’s unclear if these are always strings, especially the use of the render functions. I think these should be null checked (for both vars, in both cases) and not use phutil.

Similar here it seems the values might not always be strings so should be null-check, and both old and new should be checked

For additional context the use of the phutil function would add the intent of the value being a string so my preference is to only use it if we’re sure the variable is intended to only be of type string. Here I think it’s less clear.

Correct, this change is what I was suggesting and not trying to continue if there’s no file data. If someone is calling the api to upload a file but doesn’t give any file data that’s a user/caller error and the server-side api execution has no sensible path forward.

Thanks!

I think !strlen(trim($var)) is more semantically meaningful than comparing to the empty string but this is fine. Locating calls to strlen which do not compare its return value to another value is more indicative of a non-empty check m, and easier to identify later on

Could you make these null-and-strlen checks instead? Notice that within the strlen check it uses “renderOldValue” instead of the old value directly, suggesting it might not be a string

I agree with a more targeted change of a git-specific argument if possible

Thanks!