I've cowboy-merged this last week. Not sure why all these commits decided they are part of this task though?

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