When I said inconsistencies, I was talking specifically issues where certain UI elements have the original English version of the text, while others have the "translated" Pirate English version of the text.

I don't think that Pirate English should be consistent. Anyway I think that "Subscribers" should be translated in Pirate English and that is a bug. But what is the "Task history"?

It is almost certainly due to some DNS config. Modern email provider expect a ton of different config in there, and they are quite tricky to get right.

FYI, I believe I'm encountering similar issues. Our organization just switched to a new email domain hosted on Microsoft 365 and when attempting to add the new email address to my account on this installation, I do not receive an email with the confirmation link.

This revision is nearly impossible to test

Did we ever find out more about the hosting situation for phorge.it?

I changed everything branded Phabricator in th 10k files in my fork to Phorge and applied this change to filenames.

i can see a few mentions of Phabricator on the documentation, i am not sure if its because the documentation was left out, or because there are some elments in the codebase that still mention phabricator.

As in E14, this is really important for protecting us and contributors.

In T15026#3074, @jeremy.norris wrote:

Wouldn't it just be easier for users if the current Phacility/stable was merged into Phorge/stable, thus avoiding the need to issue git reset --hard?

In T15026#3073, @avivey wrote:

we've decided to add git reset --hard to the instructions to avoid the merges and simplify the stable issue, avoiding the merge from multiple branches.

we've decided to add git reset --hard to the instructions to avoid the merges and simplify the stable issue, avoiding the merge from multiple branches.

In T15026#3071, @jeremy.norris wrote:

Are there plans to merge the latest Phacility/stable branch into Phorge/stable branch in order to facilitate upgrades without having local merge commits being created?

Are there plans to merge the latest Phacility/stable branch into Phorge/stable branch in order to facilitate upgrades without having local merge commits being created?

release_process has been updated.

I can agree to make a legalpad that is similar to the Phacility one.

I'll go over this to see if there's anything left to do.

Boldly closing, as L1 exists and is available to sign.

Claiming this. Now that I've done this, I will take the time to document then I will close this task.

The following task creation policy is set:

• All users can create security tasks.
• Only members of Trusted Contributors may create non-security tasks.

We've made it to y-combinator, so I think that counts.

I think we can close this now.

Should I make a draft for the starmap privately and then publish it when done?

There is no need to make a modern software compatible with PHP 5.x so I can agree to this change.

Done - deleted phabricator books.

I've updated the guide with @jeremy.norris's Aphlict instructions, and also a section about configurations we might change later.

In T15026#2840, @avivey wrote:

the Aphlict change sounds simple enough to just add to the migration guide - it's going to happen at the same time for basically everyone anyway.

Edit: Looks like this issue was raised in the PR D25006#216

In T15026#2841, @jeremy.norris wrote:

FYI, I believe I was able to create a linear history from Phacility's stable branch with the following:

Phorge:

git checkout master
git remote add phacility https://github.com/phacility/phabricator.git
git fetch phacility
git checkout -b stable_linear phacility/stable
git merge -m "(stable) Promote 2022 Week 37" origin/master

Arcanist:

git checkout master
git remote add phacility https://github.com/phacility/arcanist.git
git fetch phacility
git checkout -b stable_linear phacility/stable
git merge -m "(stable) Promote 2022 Week 37" origin/master

You can view the results on my Github here:
https://github.com/norrisjeremy/phorge/tree/stable_linear
https://github.com/norrisjeremy/arcanist/tree/stable_linear

FYI, I believe I was able to create a linear history from Phacility's stable branch with the following:

the Aphlict change sounds simple enough to just add to the migration guide - it's going to happen at the same time for basically everyone anyway.

Since the user base is probably pretty small for stable in Phorge, I wonder if it could just be deleted altogether? And then create a new stable in Phorge, that is based directly off of Phabricator's stable, then perform a squash merge or cherry-pick of Phorge master into the new Phorge stable?
I'm not 100% certain how Evan handled promotions of Phabricator master into stable (if he just cherry-picked, or he used squash merges or something different altogether)?

re: stable, I'm not sure how the commits actually relate between the now 4 branches.
I considered adding git reset --hard for stable, but I was afraid users will lose local changes.
So you have a suggestion on how to fix the guide for stable?

The master branch in Phorge is linear with respect to Phabricator's master branch, but it looks like the stable branch in Phorge was created by branching it directly from the tip of Phorge's master, instead of using Phabricator's stable branch as the basis.
It looks to me that Phabricator was cherry-picking their master to their stable, so the changeset history wasn't directly linear with their master (hopefully that makes sense?).
So the directions from the migration guide end up creating a huge local merge commit when followed if you were tracking Phabricator's stable branch.

In T15026#2812, @jeremy.norris wrote:

FYI, the guide for migration doesn't seem to work quite smoothly for folks that were tracking the stable branch for Phabricator, because the new stable branch in Phorge does not have a linear changeset history to the old stable branch in Phabricator: if you follow the directions, you end up with a locally divergent stable branch that will contain a local merge commit.
Is there a reason the stable branch in Phorge wasn't created based upon the changeset history of the stable branch in Phabricator, in order to avoid this from happening?

Also, on a separate note, the changes from T15019 cause a conflict when issuing the git pull command:

error: The following untracked working tree files would be overwritten by merge:
	support/aphlict/server/package-lock.json
	support/aphlict/server/package.json
Please move or remove them before you merge.
Aborting

Should some notes be added to the migration guide on how to best deal with this as well?

Oh actually they do work now - never mind

The GitHub mirrors still don’t work yet, those reps are empty currently.

Also, should the migration guide & installation guide point users to the Github mirrors?
This might help avoid undue load on we.phorge.it?
I'll note that the Phabricator installation guide always pointed users to the Github mirrors as well.

FYI, the guide for migration doesn't seem to work quite smoothly for folks that were tracking the stable branch for Phabricator, because the new stable branch in Phorge does not have a linear changeset history to the old stable branch in Phabricator: if you follow the directions, you end up with a locally divergent stable branch that will contain a local merge commit.
Is there a reason the stable branch in Phorge wasn't created based upon the changeset history of the stable branch in Phabricator, in order to avoid this from happening?

I'll note that the developer-mode, timezone, serious-business and production-url config settings still use Phabricator in the names

I would say the current create forms are fine, there should be 2 edit forms, 1 unrestricted one only visible to trusted users, and a restricted one that is only visible to non-trusted users (can be done with custom policy)

I’ll note that there is currently a restricted create form, for Trusted Contributors that allows anything to be changed.

Process requires 2 forms with the following modifications:

• Create task form
  • Edit Form Configuration
    • Visible To -- All Users
  • Lock/Hide fields
    • Priority
    • Editable by
  • Change Default Values
    • Editable by -- Custom (likely Administrators & other trusted projects)
• Edit task form
  • Visible to certain subset of users (like a project)

If you view a book, then view source and search for PHID-BOOK then you should find a policy link. That's the PHID of the book you're viewing.

I've written https://we.phorge.it/w/installation_and_setup/update_from_phabricator/, and I think it's basically ready for simple case (and considering we're still compatible with Phabricator in all technical aspects).

I think we're done here too? E13.

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

I've tried locally with ./bin/remove , and it appears to work. To get the phid, I've visited the page and used "Actions -> Advanced -> View Handle" - I don't have this action available here.

In T15012#2678, @avivey wrote:

I've re-generated the docs, and now we have two copies:

so:

1. need to delete the old ones, I didn't find a straight-forward way to do that
2. maybe do some http redirect from the old links to the new ones.

I've started the a draft for the Going Public announcement - {Blog Post: Going Public} - please chime in with comments...

In T15012#2679, @MacFan4000 wrote:

We should also generate the arcanist docs.

We should also generate the arcanist docs.

I've re-generated the docs, and now we have two copies:

This task may need to be triaged as high since we started by forking the Phabricator software, see also T15006: Re-brand Phorge.

We should also change the internal name to the future name of Phorge, rather than leaving leftovers. Exmaple: Some code in Fandom is still named wikia.

I got differential working under PHP 8.1 by doing a global replace of single parameter strlen commands to add the null coalesce operator

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.