This is a direct result of T15090: CVE-2022-24765 - Multi-user Git Privilege Escalation - confirmed in the Nginx error logs:

STDERR
fatal: unsafe repository ('/var/repo/1' is owned by someone else)
To add an exception for this directory, call:

As I started to thinking about the script to process the pht() files, it hit me that converting something something like:

FYI, it seemed that the issue with the wiki preview loading may be been related to tagging names... if the tags are removed, the preview loads

Nice one, thanks @Matthew!

Hmm, possibly depending on how it's hosted? What I saw when that CVE was announced on a local instance and on secure. was like the below screenshot, where the repo page was still visible but file structure and recent commits were b0rked:

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.

(I am unable to edit the document directly, would someone with the right permissions mind adding this to the agenda please?)

In T15090#2123, @Matthew wrote:

That's intentional (upstream) because it's very hard to make any actual attack with this information can't be made without it.

Note: reporter exploited without permission

In T15090#2127, @Matthew wrote:

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:

I don't think having people downgrade is a good idea. I think we should probably cherry-pick Evan's fix from upstream into the phorge codebase.

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:

ahh, I was wondering why my Phorge install suddenly broke - seems to be the case here too

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

err, I was trying to put it out as a Security PSA, so I clicked "Create security task" which I guess is the opposite of a PSA...

I'm setting the "Moderate" policy on Ponder to Trusted Contributors and I'll add a link to Ponder from the default home page.

Some initial findings on Rector...

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.

Alright, I've just went through a similar process - they apparently have changed their process a little but there still is a form to fill out: https://support.microsoft.com/en-us/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3 (you need a Microsoft Account to fill it out, but they'll contact you on the contact email you give in the form)

Obviously spam.

Reordering milestones is convenient when you want to treat milestones as workflow steps rather than sequential numerical versions.

In T15082#2028, @golyalpha wrote:

epriestley was very much against this idea but wikimedia's users loved it.

Do we have epristley's reasoning as to why he was against this? Might help in deciding about including this patch in Phorge.

Since all changes are going to be submitted to the upstream prior to landing here in Phorge it would be easiest if changes were made to a clone of Phabricator and not a clone of Phorge.

epriestley was very much against this idea but wikimedia's users loved it.

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...

A few thoughts. This sounds like a great idea as searching by article title seems a little fragile as you mention. I think a good practice for using the proposed @link would be to fully namespace it somehow like @link development.processes.i18n, though I'm not totally sure what that looks like as I'm not familiar with the Diviner format or structure. If we have the use of namespaces then managing multiple @link declarations might lead to confusion or tedious to maintain. To me this also feels more similar to something like an @id rather than @link. What are your thoughts?

A highly unfortunate side-effect of T15077: Rebrand: Tracking task is that it will invalidate a ton of translations. My guess is that upstream did not want to maintain these translations as part of the release product, possibly due to not requiring translations be part of the Phabricator release process. If we pull them into the Phorge codebase then we would likely need to update all translations for any text changes made during development, prior to release. I think it would make sense to host the translations in a repository here but I would worry about them quickly falling out of date. Handling of translations is likely a larger-sized project that we would need help managing.

As part of {E1} we reviewed this as a priority item, and have created T15077: Rebrand: Tracking task for concrete first steps forwards. There is a lot of text to update and review and that task is setup with instructions on how we're approaching it as well as listing out all the individual applications to update. Anyone interested in assisting please review that task and feel free to put your name on an application/folder, as well as ask any questions for clarification.

I put up some coding guidelines that I could recall from when I was working with upstream on example changes. I won't be back at my home office for another week so there may be some things I'm missing but I think a number of things were covered/discussed with Evan on the example changes in https://secure.phabricator.com/D21712.

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