Per discussion during {E9}

New certificate issued.

https://we.phorge.it/phame/blog/view/3/ - Security Announcements
https://we.phorge.it/phame/blog/view/4/ - Release Announcements

@20after4 Hey, this does not appear to be working. T15101 was created by a user who was not a member of Trusted Contributors

Please do not triage tasks yourself, we will integrate it into the roadmap as we go.

@speck What is the status of this change?

@avivey has fixed this on the upstream install.

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

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!

Related to T15090: CVE-2022-24765 - Multi-user Git Privilege Escalation perhaps? Revisions are stored in the database that's why they're viewable, but the main repository page requires a call to git.

@dtf I've added you to the Trusted Contributors project, so you should be able to edit the page now.

In T15090#2126, @golyalpha wrote:

apparently, Ubuntu maintainers have backported a patch for the older version of git in 20.04 LTS, downgrading to version 1:2.25.1-1ubuntu3 seems to be a temporary workaround, losing the following patches:

We need to cherry-pick and import the changes Evan made into the Phorge repository as well...

As discussed in {E2}, we might add temporary banners to Diviner to state that we are rebranding. This would allow some time for us to handle the code rebrand and address the underlying Diviner issues before we edit everything twice.

As discussed in {E2}, we will be implementing this to control spam for now. If this doesn't work, we will revisit this discussion.

In T15012#1283, @MacFan4000 wrote:

I will note that also the tech docs aren’t fully generated since there should be docs for most of the phorge/phabricator classes. Also the arcanist docs aren’t generated at all.

Thanks for your comments! Namespacing might be useful, we would have to figure out what that looked like. I was thinking "/book/group/link" as that would be pretty natural (and is very close to what Diviner does already: "/book/group/filename"). It would also allow for us to eventually make Diviner widely useful, see secure: T4558. However, that is a broader discussion that should probably wait...

I am closing this, future meetings are scheduled now. See March 21, 2022 for more information.

In D25035#1059, @speck wrote:

Real quick before landing -- should this change be made here in PhabricatorUser or would it be sufficient in PhabricatorPeopleProfileController? Placing it here affects the profile at the data model source which would likely cause the same blurb-scrub in any other location it might render, but it might also cause problems in areas which need to access the profile data for other reasons other than rendering, e.g. if a profile gets copied/cloned in memory then this might result in losing the profile data altogether. Updating only PhabricatoPeopleProfileController to call cleanupProfile() instead of within PhabricatorUser would only scrub it at the time it's being rendered (to the profile page at least).

In D25035#1051, @speck wrote:

I'm having trouble landing this, I keep getting 403 errors. I suspect it's a local configuration issue, though...

All that should be required to land is being in Blessed Committers I think, which you are a member of

Address code review comments

In T15080#1970, @speck wrote:

Unfortunately this type of issue is in an area that's beyond my network/configuration experience. Is CloudFlare our NS provider?

Thank you for the review, @avivey !

Closing this task now, to prevent it from turning into a perpetual task.

As discussed in {E1}, we will actually add another action aside from "Disable Account." This action will mark the account as a spammer, which will take the following non-distructive actions:

The choice to not allow administrators to edit profiles is a strange one... at the very least, we should probably upstream Mukunda's patch.