epriestly pushed basically-identical but cleaner fixes for these in https://secure.phabricator.com/D21849

To be fair, I wouldn't discount already needing access as a viable attack vector, even on private installations.

It sounds specific to people who already have access, thank you -- do very much need to pull in latest

The disclosed issue is that someone can gain access to Files objects they don't have access to by, for example, getting someone with permissions to edit a task they wrote (by including a reference to that file which gets "activated" when the person with permissions to view it saves the edit), which makes the file accessible via the task description.

Thanks -- Offhand do you know if this is related to login in that a malicious actor can gain access to source code when unpatched?

Upstream-T13683

IMPORTANT: This release mitigates a severe security issue which allows attackers with few permission to gain access to files they can not otherwise see. All installs are strongly advised to upgrade.

FYI today's release (2022 week 21 stable) has a some pretty serious security content

@dcog I think the differences with the Harbormaster changes are due to the different approach taken. We planned to do the approach which you took in D25036 which re-played the Phorge diffs on top of phabricator, however in D25040 I just did a merge of the phab/master branch into phorge/master where the Harbormaster changes already existed. Since upstream didn't modify the same Harbormaster files there were no conflicts and things merged appropriately. I did a sanity check of files changed on D25005 with the files changed on D25040.

Do we even have servers to run the tests on?

In T15094#2292, @speck wrote:

I did not think we had Harbormaster set up to run unit tests - I think that involves configuring both Harbormaster and Drydock, and possibly Almanac which I don't think anyone has done.

I'll go back and review those Harbormaster file changes. Thanks for pointing that out!

In T15094#2281, @dcog wrote:

This would be a legitimately good exercise to try and do "properly"... although, the thought of not doing it optimally can be a bit of a barrier to starting..

Given the edge cases outlined in T15094#2279, would there be cases in step 2 (or 1?) from T15094#2259 that might benefit from Git cherry-picking? @golyalpha, any thoughts on that? I nearly never have to use cherry-picking, or maybe I should, but either way I'm not very familiar with it other than I'm wondering if it may be relevant

After some reading I'm finding that, as far as I can tell, it's not designed to pick/integrate *specific lines* from a diff, but rather a specific whole commit (from any local or remote branch most likely).. if I'm understanding it correctly

But, perhaps, it could still have the same effect as removing lines from one, and keeping lines from the other when grabbing specific whole commits

The more I think about this the more I'm confusing myself, but hopefully some fraction of this makes sense

I did not think we had Harbormaster set up to run unit tests - I think that involves configuring both Harbormaster and Drydock, and possibly Almanac which I don't think anyone has done.

I would think that your method produced the results we want... though I was noticing this:

I see it looks Harbormaster itself does the testing?

My vote is that if tests pass we go ahead and do the thing.... More changes in upstream seems fine, and moving forward if we keep up it should get easier and easier hopefully

Oh nice!!

Though it does appear additional work has been landing upstream today

Any concerns about landing those changes? Once I land I'll see about updating this instance which should make accessing the repositories possible again.

I had to skip unit tests because phabricator/phorge unit tests require a local database to test against which I don't have setup. The lint failures are either pre-existing TODO's being flagged or the newest lint which catches product name literals. We should fix the literals but I don't want to fix that as part of the merge -- would rather do that in a separate change.

Unit tests all pass. For the two lint errors, one is erroneous checking characters used in a non-code file, the other is pre-existing and fine to leave alone.

Merged the arcanist repository in D25039

This would be a legitimately good exercise to try and do "properly"... although, the thought of not doing it optimally can be a bit of a barrier to starting..

@dtf Pointed out that this thread on secure is highly relevant:

Thinking that based on the first item in (2) Rebrand here: https://we.phorge.it/w/planning_meetings/2022-05-03/#agenda-items-and-notes

Here is one thing I noticed... In at least a couple of the files, there may be changes that:

Referencing a comment from the earlier document:

I inspected the code in some detail and i figured out how to get the default value of a custom field. In a first attempt to solve my issue i tried to only show a field value in the property list of a Task if its value differs from the field default value but this does not work because i can not get the current field value this way:

@speck I saw you commented earlier about this and am not sure if this was something you managed to do, or if you wanted someone else to handle the task?

If we merge, a force-push should not be required - unless you mean something other than standard git merge here. (Force-push is required when rewriting already pushed history - git merge simply adds a new commit that applies the changes on top of the branch)

It looks like upstream has issued a number of updates which we'll want to pull in. From {E4} we discussed doing the following:

Set up two blogs: Security Announcements and a Release Announcements.

In T15096#2233, @speck wrote:

Thank you for these write-ups, I'll need more time to review however I noticed Evan recently started a task in the upstream where it looks like he's investigating compiling PHP to a library for use with a custom native entrypoint which would allow distributing arcanist as a single binary (he estimates ~10mb in size).
https://secure.phabricator.com/T13675

In T15048#2214, @20after4 wrote:

Does anyone else feel that this is not a good idea? Seems like the consensus here is that it's at least acceptable if not desirable to have.

Thank you for these write-ups, I'll need more time to review however I noticed Evan recently started a task in the upstream where it looks like he's investigating compiling PHP to a library for use with a custom native entrypoint which would allow distributing arcanist as a single binary (he estimates ~10mb in size).
https://secure.phabricator.com/T13675

Evan recently landed a boatload of changes to address this under https://secure.phabricator.com/T13658

Definitely agree that the effort to set up arcanist isn't huge. And at my current work, it's baked into our common Dev PC setup, so it's almost zero effort. But there is an effort, and a dev/user who is just passing by to fix a typo or suggest a one-line change in some code isn't going to be willing to do that effort.

This seems sensible to me, FWIW

@micax: Good points and it's helpful to hear another perspective on this. From my past experience using Phabricator on a corporate team I definitely think that arcanist helped keep everyone's workflow consistent and simple.

I find this rather interesting (and a little bit weird, to some extent), because IMO the arcanist command line tool is one of the things which IMO _add_ value to Phabricator and sets it apart from it's alternatives.

Fix line length

celerity map

Does anyone else feel that this is not a good idea? Seems like the consensus here is that it's at least acceptable if not desirable to have.

I did a bit of digging through the source code and it looks like tokens are implemented in an incredibly generic way, such that it wouldn't be at all difficult to add tokens to comments. I think the hardest part will be integrating it with the UI.

In T15090#2141, @avivey wrote:

In T15090#2123, @Matthew wrote:

@avivey Would it make sense to add a public announcement to Diviner or Phiction? Or perhaps we use Phame for this use case (Create a "Security Incidents" blog)? I always think of a task as an actionable item, whereas we would want this to exist forever.

Yes, probably. "Announcements"-style thing

@speck Would it be totally unreasonable to instead do:

As of right now, we have made no changes to the database and other "internals" - our work has been focused on rebranding as "Phabricator" is a trademarked name. For this reason, a rough migration path would be to check out the master branch of rP, copy the config directory from Phabricator to Phorge, and then point Phorge to your Phabricator database. I have tested it myself locally and it appears to work, however; if you have any issues feel free to ask a question on Ponder here and we can get back to you!

translations,The rebranding approach of changing the pht() keys will invalidate a lot of existing translations. Investigate if there are ways to avoid this.

We are now at a decision point where we either install Phorge from Scratch or migrate Phabricator to Phorge.