I'm available to configure an inboud email receiver via a simple IMAP spooler, thanks to this:

Thank you for your work on this, Dan!

(should also include the rHP -> /home/ stuff)

Per discussion during {E9}

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:

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.

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

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

Another one popped up: https://we.phorge.it/p/seo-auckland/

Yeah admittedly what I did was just a hack because I didn't want to implement storage and UI for a new "hidden" boolean flag.

Now that I look at this some more, this isn’t quite done - there are still some components of phorge that are missing projects.

I’ll note here that I’m going to work on creating projects for some of the prototypes that do get used.

In T15001#1011, @MacFan4000 wrote:

In T15001#980, @MacFan4000 wrote:

Just a note that Trusted Contributors can’t self grow beyond admins adding people currently as to add members you need to be able to edit the project. Currently only admins can edit the project.

IMO the edit policy should be set to Project Members. This way it’ll be able to self grow. :)

In T15001#980, @MacFan4000 wrote:

Just a note that Trusted Contributors can’t self grow beyond admins adding people currently as to add members you need to be able to edit the project. Currently only admins can edit the project.

Just a note that Trusted Contributors can’t self grow beyond admins adding people currently as to add members you need to be able to edit the project. Currently only admins can edit the project.

Yea I think it will be easiest to host this on the same server that's running we.phorge.it. If we're able to build it as an extension application for phabricator it can be setup in the same installation and then we can route the web server to host it properly.

I think that the best choice is to keep everything in one place, so create the presentation site on the same infrastructure of we.phorge.it

sorry for late reply. I can start working on it now. Where will be it hosted? Do you have some preference? We can use also my company infrastructure and change DNS record for a 3rd level to point to the IP.

In T15000#888, @MacFan4000 wrote:

And also we perhaps should have an IRC channel such as #phorge on Libera. It would be possible to bridge it to Zulip.

For this phorge instance, I think we should configure auth providers to allow logging in with Github/Google etc.

Per discussion on Zulip.

In T15008#651, @speck wrote:

@jupe yea I figure similar to the Phabricator landing page on https://phacility.com/phabricator/ I think we want a basic static page which showcases the project & features, along with some form of T15010, then points to the other content on this install.

In T15008#619, @deadalnix wrote:

In T15008#573, @jupe wrote:

should we also start working on the content?

Yes. If there is something that is obviously useful and that you know how to do, then please do it. You'll be adding a ton of value.

Definitely -- I believe the idea that @avivey is aiming for is something extending AphrontSite which would serve up this static page/content, then we can update nginx to point phorge.it to that site leaving we.phorge.it to point here. If you'd like to start putting together the content or learning about extending AphrontSite that would be a great help.

@jupe yea I figure similar to the Phabricator landing page on https://phacility.com/phabricator/ I think we want a basic static page which showcases the project & features, along with some form of T15010, then points to the other content on this install.

In T15008#573, @jupe wrote:

should we also start working on the content?

Question: while we figure out how/if we host the site itself with phorge, should we also start working on the content?

I think this is complete.

I'm going to call this done, since we have a stable dashboard set up now.

Oh, excellent! Thanks for looking into that.

In T15000#408, @speck wrote:

It looks like Diviner was used to generate documentation however a lot of the documentation still refers to "Phabricator". We'll probably want a separate task just for reviewing and updating all the documentation to make sure it's appropriate.

Btw where is the source for the diviner books and how does it get generated?

(It's all in src/docs and can be generated with ./bin/diviner generate)

It looks like Diviner was used to generate documentation however a lot of the documentation still refers to "Phabricator". We'll probably want a separate task just for reviewing and updating all the documentation to make sure it's appropriate.

Something was funky in how the repo was originally imported that was causing the issues. Somehow got to a state where it wasn't properly a bare repo (there wasn't a working tree, but everything was still inside .git/ instead of the root folder). Not sure how that happened, but seems to be resolved now

• we.phorge.it works fine in Chrome, but arc has some issues w.r.t. CURLE_SSL_CACERT; I expect it might solve itself after a restart/update of my local machine.
• git fetch from the new uri shows no errors
• the push dragon still thinks rP51cb7a3db9 to 2abd75c162 is not fast-forward.

Infrastructure setup is being documented in server

Okay I think everything is setup for the migration to we.phorge.it

• I added a port 80 configuration for we.phorge.it to nginx
• I ran certbot to grab a cert for we.phorge.it, I used --nginx
• I updated the nginx conf file to clean up the automatic modifications and setup secure.phorge.it and secure.phorge.dev to redirect to we.phorge.it
• I updated phabricator.base-uri to use we.phorge.it
• I updated notification.servers to use we.phorge.it
• I restarted nginx

Okay I'm going to try swapping out the URL for we.phorge.it. If everything goes well everyone will need to update their URLs and clone repos. If things don't go well I'll, uh, glue it back together

Notifications are also functional. Took me a minute to remember where the "test notification" feature is located (it's in your user settings > notifications)

Whoops, commented on the wrong task, tested imagemagick in T15006#314

I'm going to get aphlict up and running before looking at changing the domain name stuff. Not having notifications is kind of a bummer.

(I verified by starting a new ssh session over port 2222 and freshly cloning phorge after modifying diffusion.ssh-port)

The ports are switched

• Administrative port is now 2222
• VCS port is now 22

Hah yup, we're all good in case everything catches fire. I'm around all evening and can revert changes if anything goes haywire

@chris I'm looking to make the SSH configuration change shortly, having the administrative ssh go over port 2222 and vcs go over port 222. In the event everything goes horribly wrong does someone have physical access to this machine or some other control mechanism?

I have some step by notes in our internal instance for getting SSH going - If you get stuck let me know and I will parse them into a public readable format

Thanks @speck! I think we also need to update the NGINX config and phabricator.base-uri config to we.phorge.it from secure. Will also require updating the clone URI. You want to just bundle both changes at once to make things easier? Looks like @deadalnix already updated DNS so that should be hunky dory

• move administrative SSH to port 2222

This one is going to require that everyone who currently has a cloned repo to update it, correct? I'll take a look later tonight at swapping this out, as the sooner the better IMO. I'll comment here before making the change.

I created Release Process for the release process.

Maybe create ssh.log file and chown it to git? and hope that's the only file it needs to write to?
I'm guessing from the name that it's only used by the SSH flow.

In T15000#289, @avivey wrote:

https://secure.phabricator.com/book/phabricator/article/diffusion_hosting/

I think /var/repo should be owned by git:

The user the daemons run as. We'll call this daemon-user. This user is the only user which will interact with the repositories directly. Other accounts will sudo to this account in order to perform repository operations.

The release strategy of Phabricator was:

• everything goes into master asap, unless it's dangerous
• once a week, master gets merged into stable
  • after that, all the "dangerous" stuff lands to master
• important stuff that comes up during the week gets cherry-picked to stable.

Yeah, logging perms should (I think) be fixed now. I was dumb when I chowned things and forgot what system users needed what access.

I think /var/repo should be owned by git:

I think secure. had instructions about file ownership - looking...

Do we have a documented release strategy? I'm not very familiar with git and I only have a vague sense of what Phabricator's release process was. I think it's something like

• Accepted changes are landed into master
• Evan cherry-picks changes from master into stable to "release"

Possibly with some additional smoke-testing somewhere in all this?

I think there might be some permissions issues with the log location but I'm not sure if it's the root cause of the issue being seen here.

That one is totally my fault - 4042d24d74 is a local commit I have (updates .arcconfig). But I was trying the push from a different commit, which has 51cb7a3db9 as its (only) parent.

Same with a patch workflow against a fresh clone of the repo:

phorge  (master)$ arc --config phabricator.uri=https://secure.phorge.it patch D25000
 INFO  Base commit is not in local repository; trying to fetch.
Created and checked out branch arcpatch-D25000.

git version 2.32.0.rc3 locally; 2.25.1 on the server. Both reasonably recent...

In T15000#277, @avivey wrote:

Also won't let me push, because something thinks it's a non-fast-forward (it is, unless I'm drunk):

In T15008#278, @avivey wrote:

I think we want an Application in an Extension...

I think we want an Application in an Extension...